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.

See merge request nexedi/erp5!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 !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.

to ensure no regressions in legacy UI

When the preferred text format is set, the default value of the text editor
for the reply body shows the original message quoted.

Also remove a non applicable copy-pasted comment

See merge request nexedi/erp5!1395

Revert "erp5_officejs: erp5_hal_json_style Skin is used and without it erp5_officejs cannot be installed."

This reverts commit 1b706b6c. erp5_officejs
depends erp5_web_renderjs_ui which in turn depends on erp5_hal_json_style.

There is no such as thing as "Long Title" in erp5
There is "Title" and "Short Title"