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:
There are some utility scripts in erp5_forge/erp5_toolbox skin folder.
Does the appearance of list fields differ depending on region, role, function etc.?
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.
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)?
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)
(Event is a normal case)
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.
What about localised form boxes (ex.. Japanese address is
not same as French and FormBox must be used)
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.
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)
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.
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.
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.
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.
Yes, all fields in generic business templates should be proxy fields. If you
find a non-proxy field, it is a mistake, a bug.
Why is it better to use proxy fields in generic business
It allows easier customization in customer projects and help having consistent user interface.