This reverts commit e50d05af.

Do not access form submission REQUEST from the listbox list method,
as it is rendered asynchronously in ERP5JS

This reverts commit 35b2c024.

Allow edition in the new UI

This make everything slow as hell and prevent to quickly save.

Example: <h2 class="foo">bar</h2> => <h3 class="foo">bar</h3>

erp5_web_renderjs_ui: keep previous focus color

This reverts commit a87db49b.

This front page gadget allows user to:
* create any kind of document
* launch any kind of report
* contribute a new documents

This gadget can be used to replicate the xhtml access page.

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.

See merge request nexedi/erp5!1394