When rendering reports, deferred style was only keeping request.other, but
some places, like Products.ERP5Form.ListBox.ListBox.getParamDict read only in
request.form, which caused different behaviours when rendering reports
directly or in activities, because when rendering in activities request keys
that the report dialog might have pushed were not preset in request. They
were of course present when rendering the report directly, because this was
the same request, so this lead to different behaviours wether reports were
rendering in activities or directly, like we could observe in 7058ab6f
(accounting: fix grouping option of GL when running in deferred mode, 2021-02-25)

This change deferred style to properly propagate request.other and
request.form in all activities of reports.

Calculate link to allow Nexedi developers access the ERP5 fields, forms and form actions from it.

* erp5 form gadget handle links to access from and form action
* label field gadget handle links to access field configuration, title
and descriptions translations
* page action handle all links to access workflows and portal type document
* add generic function to merge action with raw actions by group

* Add sample of action that allow uses access slideshow from ERP5JS

ERP5 uses a mix of context.REQUEST and Products.ERP5Type.Global.get_request(),
which now uses zope.globalrequest.getRequest().
CMFActivity reconstruct the original request before executing activity, so that
the activity is executed with a request equivalent to the request at the time
where the method was activated. For this, context.REQUEST was properly restored,
but get_request()/globalrequest was only restored when the REQUEST had some
Accept-Language header, so that it replays the language negociation for
Localizer.

With browser requests, I guess every browser pass an Accept-Language header (
according to https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Language
all major browser support it), but within unit tests such header is not present.
So this lead to activities with unit test requests being slightly different,
because as they don't have Accept-Language, context.REQUEST was set, but the
global request was not set, so they were running with two different requests
in context.REQUEST and global request, leading to some problems for example
with formulator fields.

See merge request nexedi/erp5!1357

See merge request !1381

as an extra safety measure

and also addition of comments

instead, check for the specifically expected Exception
and in that case return with a warning

Commit updates also testDelete of listbox_zuite accordingly

See Alarm_generateReportDocumentList for the full API and the test for example
usage.

This enables reuse of deferred style API to produce a report, but do
something else with the report.

Split a reusable test base class and use self.username variable.

Also don't set username as reference on person, this is no longer needed
since ERP5 Login.

7a9d47adff (authentication_policy: fix display of password expiration date, 2021-03-25)
was wrong, the date was not properly substituted in the message.

This constraint had a TALES expression making it not apply on invalidated
accounts, but during the transition invalidated -> validated, when the account's
consistency is checked, the account is still in invalidated state, so that
check was ignored, making it possible for users to validate an account without
and account type.

- Use Message, so the comment is translated in display time
- Do edit only if we have some objects deleted from ZODB

- Remove useless conditions of "if True"
- No use to use try-except-else, since all except branches
either raise or return
- Remove trailing whitespaces

* Soap Duplicate and Soap Cancel functions have been discontinued due to lack of usage
* OrderId is now necessary in order to retrieve Transactions

My suggestion of using sorted in
nexedi/erp5!1373 (comment 129103) was wrong,
ERP5 document do not sort in deterministic order. Use a key function to make
sure we get results in same order

See merge request nexedi/erp5!1373

For two reasons:
- In previous version, query would lose Embedded Documents, lacking a left join in follow_up_uid
- In large instances the previous version was many times slower

Also,
erp5_dms: Add a test for Base_getRelatedDocumentList

To check it works correctly with both related (follow_up)
Documents and with sub-object Embedded Files

in 772d8fed (configurator_standard: use specific sale and purchase
business processes, 2020-07-16) we introduced scripts to look up
dynamically accounts to use for expense/income and VAT accounts, from
supply lines, but this accidentally broke the case where no account can be
found on supply lines: in this case, the accounting line was not generated.

Ideally, there should be fallback accounts, to keep the same behavior and
also to prevent generation of incomplete transactions.

Review the scripts, so that the "Dynamic" scripts fallback on the account
defined on the trade model path if not found and introduce new scripts,
where the account is not taken dynamically, but only from the trade model
path, for use on the payable/receivable lines (where we don't want to
lookup the account dynamically, otherwise we'll use same account as for
expense/income)

This omit_grouping_reference key was not set as selection parameters, so
Node_getAccountingTransactionList could not find it in selection when running
in deferred mode.

In non deferred mode, it was working, because selection is set with values from
request and it was same request, but deferred style uses activities, so it's
different requests.

When IBAN is defined, use it by default for reference. IBAN is used by
default all over europe, so when it's set it should be used by default for
reference.
Mixing IBAN and other properties does not make sense, so this change
should not have unexpected side effects.

We also update "edit_order" on BankAccount_view so that title properly
fallbacks on reference when reference is iban.

To ease "manual" (ie. not from payment rule simulation) creation of payments,
update "create relate payment" so that it suggests the payment mode and the
payment date from payment conditions of the invoice's trade condition.

See merge request !1369

Use editor gadget to render the output as raw data.

Use the page class to improve xhtml style rendering

* enable more elements/attributes
* show table cell's border
* reduce table width
* support align="center"
* only use sans-serif font like ckeditor