DCWorkflow to ERP5Workflow: copy or move some Workflow form to be used only on Configurator Workflow

Design of Configurator Workflow is kept as it is. But Workflows were changed a lot. So some
parts of configuration of Workflow is copied for Configurator Workflow

Work partially done by:
- Wenjie Zheng
- Isabelle Vallet

We already had several portal types for workflows in erp5_worklow. Since we will soon use
ERP5 style workflow by default, portal types must be part of core business template.

We already had several forms for workflows in erp5_worklow. Since we will soon use
ERP5 style workflow by default, forms must be part of core business template. Changes
to forms will be commited later.

Transition of Interaction Workflows are now ERP5 objects, thus needs to have propertysheet

Work partially done by:
- Wenjie Zheng
- Isabelle Vallet

Guard was only handled as an expression. To fully support all features of
guard, a complete propertysheet is required with group, permission, role,
expression.

Work partially done by:
- Wenjie Zheng
- Isabelle Vallet

Move specific Transition properties of Configurator to a dedicated propertysheet.
Configurator could be reviewed further later to share more code with new Workflows.

Work partially done by:
- Wenjie Zheng
- Isabelle Vallet

Worklist are now ERP5 objects, thus needs to have propertysheet

Work partially done by:
- Wenjie Zheng
- Isabelle Vallet

ZBigArrays were omitted from being saved in notebooks in 5fb16acd
(erp5_data_notebook: Don't save ZBigArray in data notebook. It may be
too big that zope process may crash.).

However since ZBigArrays are regular ZODB objects with persistent
references to other ZODB objects there is no reason for us not to be able to
serialize them.

Add corresponding FIXME with link to more context.

/reviewed-by TrustMe

Currently the full-upgrade alarm calls the 3 upgrade-related-alarm's activeSense methods in activities. As activeSense method runs Alarm's methods in activities too, the final activities do not get the good "tag" and "after_tag" values, which creates a lack of depency between them. In consequence, if we are not running the real upgrade (= just activeSense), no need to run post-upgrade's activeSense : indeed, post-upgrade constraints will be run on what are *currently* installed, and not on the result of the previous steps of the upgrader, which lead to a wrong and misleading consistency check.

This Merge Request intends to fix it by : 
   * Adding a "activate_kw" parameter to activeSense method, which allow to configure its internal call to "activate"
   * Improving upgrader to remove the useless calls to activeSense, and properly parameterize activeSense's activity generation 

/reviewed-on nexedi/erp5!276

For new developments, we should use portal_components. So move theses tests to
portal_components before Workflow changes.

There is no selenium tests yet, but at least we can see the same graph rendered with different
gadgets. Later, we will have to find smart ways for testing graphs

[erp5_officejs_appstore_base] configuration_latest_version is set when acception the Software Publication

Fix web section templates.
Fix appcache for the redirect app.

FullUpgrade Alarm relies on getLastActiveProcess to return results, which makes
use of the catalog to return a result. If the Active Processes spawned by the
3 Alarms composing the upgrader (pre, upgrade, post) are not indexed before
the FullUpgrade Alarm collects the results, then the wrong active result is
returned, which then give the wrong feedback to the user.

It seems that the "defaultActivateParameterDict" method cannot overwrite
the "tag" parameter of indexation activities (even if it was working for
after_tag). This is why this commit is needed.

to fit original script behavior, from erp5_web skin folder.
Also fixes "KeyError: TraversalRequestNameStack" from
`WebPage.getDocumentValue(reference)` on the "View" skin selection.

This activate_kw is a dict passed to internal 'activate' called
in order to more controls on activities created by activeSense

As results may be inconsistent as long as pre-upgrade and upgrade steps have been run for real

To make it easier for users to change their preferences, so that they do not have to create the preference themselves, we tried to pre-create a user preference ready to be configured for each user.  

It was 59860df3 :  an interaction to create a user preference on `Person.setReference` which is more or less the time when this person become a user ( but not really - this was already a weakness of this approach).

This calls `Person_createUserPreference` that initialize the preference by introspecting the assignments of the person. This already had a problem that it was working only if the assignments were created before the reference was set on the person.

With the new user management introduced in !185 this interaction moved to `Person.setUserId`, which is called in Person's init script. This had the following problems:
 - All persons have a user id, so all persons have a preference. For sites with many persons that are not actually users, this create useless preferences.
 - During init, person does not have assignments yet, so `Person_createUserPreference` could not use information from assignment to create preference.

The suggested change is to create the preference only when the user click on *Edit my preferences* button.

This is done by adding a new `portal_preferences.getActiveUserPreference` method that returns the active user preference and create it if not already existing, this way we do not have to put logic in the user interface scripts.

All *Edit my preferences* links should use it like it was done in f62e6651

The `person_interaction_workflow` was completely remove, as the other interaction it was containing - clearCache when deleting the person - was useless . We had to adjust a few tests that was passing thanks to this interaction.

/cc @gabriel @vpelletier @kazuhiko @tc 

/reviewed-on nexedi/erp5!273

Base.edit has this feature of not actually modifying the properties when
the new property value is same as the current one, so when we do
`movement.edit(price=x)`, this will cause an implicit getPrice.

As price lookup is a bit slow, do not lookup price in this case.

/cc @vpelletier @kazuhiko @romain 

/reviewed-on nexedi/erp5!259

Fix for [#20160719-1B69F57]( https://nexedi.erp5.net/bug_module/20160719-1B69F57 ) 

These after clone methods in transformed resources are being too clever and behave very badly when the transformation itself is cloned.

The suggested approach is to stop initializing int index & reference when cloning transformed resources ("transformation lines"). This behavior is kept when adding new transformed resource. This become consistent with what we have, for example, with Sale Order Lines in Sale Orders. 

/cc @luke @seb @gabriel @kazuhiko @romain @Nicolas 

( see also nexedi/erp5!148 for more )


/reviewed-on nexedi/erp5!258