Always use accessors to access / set object properties

Object attributes should always be modified through a method call. Modifying an object attribute by accessing an attribute is considered as a programming error.

Do not use invokeFactory: use newContent

If you use invokeFactory, you will not be able to manage permissions. invoikeFactory requires AddPortalContent.

Use constructContent instead:

    context.portal_types.constructContent(type_name=string.join(doAction[1:],' '),
                           container=context,
                           id=str(context.generateNewId()),
                           RESPONSE=request.RESPONSE)

Never associate a module to a workflow

Modules (which use the class Folder) should not be associate to a workflow. Otherwise, they will likely be unaccessible by users because of permissions settings in the workflow. To manage security of a module, use the ZMI.

Category accesors and properties

ERP5 automatically generates Category Getters (eg. for a category called destination a method named getDestinationTitle). However, it does not generate a setter (eg. setDestinationTitle). This may lead to unpredictable errors. Currently, if in a form, a property related to a category can be edited (eg. with a RelationStringField), the _edit function of Base will receive a property value as input (eg. destination_title) which corresponds to nothing defined in a PropertySheet. It will likely store it as a python object attribute, after trying to call an acquire getter method. This is very dangerous.

Therefore, here is the rule

• only use automatic category property getters to access properties (an nothing else).
• always define properties in a PropertySheet if they can be modified by a RelationStringField

Rationale:

• ERP5 was designed to be used in a pure documentary environment (without relations). This required to define specific properties (eg. destination_title) which were only meant to store a string, rather than define a relation. Relations were added later.

Naming Workflow Variables

Rule: use different id for catalogue variables which may be used by 2 non exclusive worklows

Rule: use the same id for variables which have the same meaning and are used by exclusive workflows

Rule: use the same id for variables which have the same meaning and are not catalogued

Briefly: only use different id for catalogued worklows variables which belong to non mutually exclusive workflows. Example: state variable.