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.

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 !1394

ERP5Type.Core.Folder: bundle parameter configurable on folder migration and higher migration priority
- to ensure the number of activities doesn't increase infinitely with large module contents and to prevent conflicts on the module itself

new id generation script

Since slapos@0aaa1ccd
cloudooo fonts are now configured correctly.
The snapshots from these tests have been expecting the old, wrong fonts.

This update snapshots to use the new fonts, so that we can
update production cloudooo used for tests.

In e559ecd5 ([erp5_crm] Activate actions for ERP5JS, 2019-09-25) we introduced
a regression, support for erp5_xhtml_style got broken in "Create Response"
when enabling ERP5JS.

It was fixed later in 3125590f (fixup! [erp5_crm] Activate actions for ERP5JS,
2020-10-23).

This extends test coverage for:
 - "Create Response" in erp5_xhtml_style
 - "Create New Event" in both ERP5JS and erp5_xhtml_style

See merge request nexedi/erp5!1397

When rendering error page, the default header_title is computed in global_definitions
and this is done by concatenating string:ERP5 (which is unicode) and the
title of the portal (which is an UTF-8 encoded string), which causes an
UnicodeDecodeError, because the portal title was decoded as ASCII.

Because header_title is usually an UTF-8 encoded string, also use an UTF-8
encoded string for 'ERP5' default value.

Following current convention of having x_ui_test for the framework and the
xhtml style tests and x_renderjs_ui_test for the ERP5JS version of the tests.