This reverts commit 9c326322.

When there is a invalid field, we trigger a notification if the user tries to save the form. But, if this notification is triggered, we don't trigger an alert when the user clicks in another page to leave.

But, if the field is invalid, the user does not click in "Save" and try to leave, the alarm is triggered.

Workflows are ERP5 Document now, we stay inside ERP5JS intead of go to ZMI

erp5_web_renderjs_ui: Display dev action to gadget field and avoid duplicated actions to parallel field

And avoid random failures

See merge request nexedi/erp5!1362

This case breaks action calculation between xhtml style and ERP5JS.

See merge request nexedi/erp5!1403

As per the discussion on nexedi/erp5!1378 (comment 131223)
what's important for this test is that the value is high. It seems the test
was not updated to the final version. We now have 35, not 36.

state.getId() now have a prefix, we want to use state.getReference() here.

ERP5Workflow: Remove unused variable_default_value and use variable_default_expression instead (!1378).

ERP5Workflow: erp5_configurator_*: Migrate Configurator Workflows from workflow_module to portal_workflow (!1378).

Migration Procedure: With your current instance:
  1. Update erp5.git
  2. Start your instance.
  3. Upgrade erp5_property_sheets, erp5_core and erp5_configurator bt5s.
  4. Add an External Method for the module migrateWorkflowModuleToPortalWorkflow and the function of the same name as the module.
  5. Run the External Method to convert them from workflow_module to portal_workflow.
  6. Move all workflow_module from PathTemplateItem of your Business Template to Workflows and commit.

This also moves all Configurator Workflows in workflow_module to portal_workflow
(workflow_module was an implementation of Workflows based on ERP5 objects and
not using DCWorkflow code).

* Workflows are now defined on on portal_workflow._chains_by_type anymore but,
  as everything else, on the Portal Type itself.
* portal_workflow can contain and work at the same time with legacy and new
  Workflows (ERP5Type/patches/DCWorkflow.py monkey-patching DCWorkflow classes
  to provide the same API).
* Existing Workflow Scripts should work as they are and the code can be updated
  later on to take advantage of the new API:
  + With legacy implementation Workflow {Scripts,Transitions,Worklists,States}
    were in a Folder ({scripts,transitions,worklists,states} attribute) but
    all of these are now in the Workflow itself and their IDs are prefixed
    (PropertySheet-style), for example `script_`. Legacy attributes are
    provided in new implementation to call the new API.
  + When calling a Workflow Script, `container` was bound to its parent, namely
    WF.scripts (Folder) and a Workflow Script could call another. Now `container`
    is bound to the WF itself and Workflow Scripts are in a Workflow directly.
    New implementation `scripts` attribute handle such use case.
  + Override portal_workflow.__getattr__ so that a Workflow Script can call
    another one without prefix.
* Worklist are Predicate: Worklist filter objects based on given criterions and
  thus it makes more sense for a Worklist to be a Predicate (albeit a Predicate
  with only Identity Criterion and nothing else).
  + Criterion Properties:
    * state_variable.
    * local_roles (SECURITY_PARAMETER_ID).
    * Any Workflow Variables with for_catalog == 1.

erp5_performance_test:testWorkflowPerformance were ran to compare DCWorkflow
and ERP5Workflow implementations and it seems to be about 4% slower with the
new implementation (legacy: 7.547, 7.593, 7.618, 7.59, 7.514 and new: 7.842,
7.723, 7.902, 7.837, 7.875).

Work done by Wenjie Zheng, Isabelle Vallet, Sebastien Robin and myself.

this is not erp5_accounting data model.