Hyper Open Edge Cloud

ERP5 Technical Note Steps To Create Field Libraries

Outline of the four steps to follow when creating field libraries.
  • Last Update:2017-03-21
  • Version:001
  • Language:en

Steps To Create Field Libraries

This technical note tries to provide help on troubleshooting security and permission based problems. Make sure you have read [ERP5 Access Permission Link], this can already solve many issues.

A procedure of making field library is following:

  • Add normal fields and forms to your business template.
  • Add only one field library in your business template.
  • Unify existing fields semantically and make their template fields to your field library. Those template fields should be proxy field of core field libraries.
  • Find fields which match common type defined in erp5_core.Base_viewFieldLibrary(my_view_mode_title for example) and add template fields to the field library of your business template.

There are some utility scripts in erp5_forge/erp5_toolbox skin folder.

  • SkinsTool_getDeadProxyFieldList: This is useful to find dead proxy fields if you have existing customized forms in your custom business template and have to merge the recent field library changes.
  • Base_checkSkinFolderForms: This is useful to check that proxification did not modify behaviour of the forms.

Questions

Q:
Does the appearance of list fields differ depending on region, role, function etc.?

A:
Field libraries are organized semantically, there will be category specific template fields like my_region, my_role, my_function in a local field library. In this way you can unify many my_region fields in your business template to one and can customize as you want.

Q:
source_title is a different field with different UI possibly between ticket and event (ie. This means source_title field for ticket probably uses proxy field of another skin than crm)?

A:
You must add my_event_source_title and my_ticket_source_title as a special template field and this template field should inherit a normal source_title.proxy order will be following: 

(Ticket is a special case)

Ticket_view.my_source_title
Base_viewCRMFieldLibrary.my_ticket_source_title
Base_viewCRMFieldLibrary.my_relation_field
Base_viewFieldLibrary.my_relation_field
(Event is a normal case)

Event_view.my_source_title
Base_viewCRMFieldLibrary.my_relation_field
Base_viewFieldLibrary.my_relation_field

In this way we can handle both special case and normal case in one local field library and because everything is in one local field library, it is easy to understand proxy field dependencies.

Please try as much as possible to use prefix which are consistent with those defined in business_fields of the Glossary.

Q:
What about localised form boxes (ex.. Japanese address is not same as French and FormBox must be used)

A:
I think there is nothing special about proxifying formbox. FormBox job is just choosing an appropriate erp5 form to embed by user language. Probably we define a naming rule for it and prepare a template field and enter a clever tales expression to extract required values to make it work, just like RelationStringField.

Q:
What about fields with a lot of many specific semantic (ex. Resources in a purchase order line should be of category use/component whereas resources in a sale order line should be of category use/product)

A:
I think preparing a template field per specific semantic is enough. In above example, add my_purchase_resource as a template field and use it from proxy fields of PurchaseOrderLine and PurchaseOrderCell.Then Add my_sale_resource as another template field and use it from another proxy fields.

Q:
If it's only used in one form, is it useful to have proxy field ? it's same amount of work to maintain customized field library than to maintain customized form.

A:
Good point. Having a proxy field is useful, because almost all fields should follow user's preference and proxy field is the most useful way to realize it. But I don't think it is useful to have dedicated proxy field for each field. That's why the current field library provides very few template fields and basically proxy is made per data type. But there is another opinion. Because we cannot assume future customisation requirement, and if we want to customise such minor fields which is used only once in standard business template, then we have to make a proxy field from scratch and it is boring. So that all fields should be replaced with proxy field. This is another opinion and we consider to realize this idea now.

Q:
Why some fields in the form displayed to the user might be not proxy fields ? Isn't it better to make ALL of them proxy field ? I can understand exceptions for project's specific forms, but it might be better to do no exception on generic business templates.

A:
Yes, all fields in generic business templates should be proxy fields. If you find a non-proxy field, it is a mistake, a bug.

Q:
Why is it better to use proxy fields in generic business templates ?

A:
It allows easier customization in customer projects and help having consistent user interface.