Announcement

Collapse
No announcement yet.

Custom field name in standard entity

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Custom field name in standard entity

    Hi,

    If I need to add a custom field in a standard entity (vatNumber in Account entity for example) what about naming convention for custom field in entity that may will be update in future release?

    My concern is to prevent safe upgrade Espo after my customisations.

    Thank's in advance

  • #2
    Hi,

    If you use the Administration panel, you don't have to worry about future incompatibility because of customizations using this facility are not affected by Espo upgrades.

    When you add a custom field this way, none of the code is affected, what is affected is the metadata, which you can think of it as the collection or settings for the application and is designed to be altered by the user without compromising any code.

    This is a high level description of what happens when you add your new field using the Administration > Entity Manager facility:

    Espo is a single page application meaning that every time that you refresh a page, the browser will make a new request to the server, and the server will do the following:

    If you are using cache and Espo determines that there is no need to create a new metadata.php script, then Espo will use the existing metadata.php values to serve a new single page to the browser.

    If you are not using cache, or you have made changes that require updating the previous metadata.php script, the server will read all metadata scripts (entityDefs, clientDefs, etc), will consolidate the information in a single metadata.php file, taking into consideration the importance or weight of each script, then will build a new single page instance to serve to the browser for display.

    For example: If you add a custom varchar field vatNumber to the Account entity, through the Administration module, what Espo will do for you is:

    a) It will create a custom entityDefs script in the Custom namespace for the affected entity (Account) with the field's specifications. These new specifications will not modify the original Account entityDefs script, but since they are in the Custom namespace, they will override the original metadata values when the server creates a new metadata.php file.

    b) It will create a new language definition json script to determine the label that your users will see when they see the vatNumber field

    c) Will create a new field vat_number in the account table (this field naming convention - camelCase for back end, dash separated for javascript and small caps underscore separated for front end and database field name) is part of Espo and you don't have to worry about it

    d) In the rebuild action, Espo will generate a new metadata.php (consolidated metadata) file, a new espo.min.js script based on your latest javascript classes (core classes, views, controllers, etc) so you can use the Account entity with the field vatNumber incorporated.

    Last edited by telecastg; 11-13-2021, 04:20 PM.

    Comment


    • esforim
      esforim commented
      Editing a comment
      Do note that is rare case where you field name or entity name matches a future update I think it won't affect you too greatly in term of data, you will need to make an update (name change) at that time with regard to the name otherwise it will clash with the defaults EspoCRM setup (reserve)

      I think I only saw incident of this happenings on the forum through my ~1 year of use. Both were major update though and the solution were easily resolved.

  • #3
    Hi telecastg and esforim sorry for the late reply, i have been busy for the last few weeks

    Thank you very much for your answers, very clear and complete.

    May be a good way develop a custom extension to easy update different enviroments as explained in these posts?
    I did not find an answer for this especially. Is there a possibility to pack a whole entity with layout, relationships and custom fields as extension so that deployment could be done easily?

    This tutorial describes how to create a simple extension based on a custom implementation and shows how to use 'Modules' to segregate customizations instead of having everything in the 'Custom' namespaces, making it much easier to manage changes and troubleshooting for your custom code. The custom implementation described here


    To begin extension developing learning is it a good way study real estate extension? https://www.espocrm.com/extensions/real-estate/

    Other suggestions?

    Thank you in advance

    Comment


    • telecastg
      telecastg commented
      Editing a comment
      I think that the above will certainly get you started. Using the real estate extension as a sample to study was for me the best way to learn about extensions

    • acuf
      acuf commented
      Editing a comment
      Got it, thank you telecastg
Working...
X