`object_report` and `object_exchange` action categories are only enabled
in erp5_xhtml_style. Use the `jio` equivalent categories so that the
generated report is also enabled in ERP5JS.

OfficeJS use another mechanism for actions registration, so duplicate
actions defined on the portal type is not necessarly a problem, as long as
all actions are not registered in the same app.

See merge request nexedi/erp5!1469

For some reports displaying transformations result to end users, it's much
better to have amount ordered in the same order as the model lines.

AmountGeneratorMixin was already sorting the lines, but the order was lost
during aggregation, because we used a dict, which on python2 does not
retain order. Switch to using an OrderedDict to keep the order.

This makes RSS reader somehow usable for support request RSS.

One important think to keep in mind is that because of a bug in how URL characters are (not) escaped in the dialog to edit character is that editing the feed URL should be edited from knowledge pad module, and not directly from front page. Also this should be edited by clicking Edit button, not by pressing enter.

See merge request nexedi/erp5!1467

See merge request nexedi/erp5!1470

See merge request nexedi/erp5!1455

To "mark as read" and open preview, the front page gadget uses the "md5" key,
which is calculated from "link", but we can have multiple entries for the same
links, like it's the case for officejs_support_request app.

Instead, use guid or id if available, this is what RSS/atom use for this purpose.

See merge request !1465

so user can login

Instead of expecting exactly actions with "preview" or "view" name, take any
action which name contains "preview" (or title is "Preview") or name is "view".

This makes it easier to include support request applications in different
applications, where the default actions might have a different name. This also
fixes the preview link for File portal type, because there was no "preview" or
"view" actions for File.

We received a few support requests from users who are able to change their
password but not to log in afterwards. These users probably copy and pasted
their user name with an extra leading or trailing space. In the reset
password dialog, these spaces are stripped, because Formulator by default
strips the input (unless "whitespace preserve" is on, but we usually don't
set it except in text areas).

Historically we have been completely avoiding the extra spaces and made the
login/user_id case sensitive, because login and user id were the same thing
and there have been issues when looking up user id in mariadb because of
mariadb collations, so we took the easy way of saying "logins are case
sensitives and spaces also mater", but with separate login / user id,
this can be revisited, because the login is only used to check the password
and find an user ID.

Stripping spaces from logins is a common thing these days (google, twitter,
facebook strip logins) which simplifies user experience and reduces support.

The risk of conflicts seems very low, if users are created with ERP5 Forms
Formulator already had stripped the login anyway. After this change in case
of two user names ('alice' and ' alice ') conflict, none of them would be
able to login.
We keep compatibility with users with trailing spaces, so if there is only
a user named ' alice ', without other users that would conflict (for
example 'alice' or ' alice'), this user remain able to login anyway. This
last part is probably not so important in reality, it is for compatibility
with testPasswordTool.TestPasswordTool.test_login_with_trailing_space

* Fixes https://erp5js.nexedi.net/#/bug_module/20160609-11B02E6 and https://erp5js.nexedi.net/#/bug_module/20210517-F12266
* Support ERP5JS
* Improve test coverage
* Small CSS changes
* Fix bug editing business process when erp5_graph_editor was installed 

See merge request nexedi/erp5!1461

Until now, portal_sessions was only reliably usable when using a family with only one zope node, because the session data was using RAM cache.
When used by authenticated users it was more or less usable, because of haproxy
sticky cookie that we set for authenticated users, but for non authenticated users
this was basically unusable.
This was especially a problem for CaptchaField, for which users are generally not
authenticated.

This changes portal_sessions to use a distributed cache, which brings several
differences:
 - sessions are now shared between all zopes of a cluster.
 - storing ERP5 temp documents is still possible, but modifying a temp document in
   session does not automatically save the changes in session, for next session read
   to be using the modified document it's required to save the document explicitly.
 - session respects transaction semantics, changes are only persisted in session when transaction commits successfully.
 - `portal_caches.clearAllCaches` API no longer clear all sessions.

See merge request nexedi/erp5!1451

See merge request nexedi/erp5!1466

See merge request nexedi/erp5!1464

There was a wrong assertion in an interaction workflow, preventing saving from
other tabs than the graph editor

- set validator, this is now required to be able to edit
- use an iframe for ERP5JS compatibility
- clean up this form, it had some unused disabled fields, remove them
completly instead

and also enable coding style on this bt

- set validator, this is now required to be able to edit
- use an iframe for ERP5JS compatibility

- set validator, this is now required to be able to edit
- use an iframe for ERP5JS compatibility

Graph layout is part of the workflow, a bit like the description.

These are rendered with a loop from the state to the state, it's ugly and not
much informative, remove them for now. We could use different edge styles for
"worklow method only" and "workflow method and user action" transitions and
render this as only one transition. We could also change the data model of
workflow itself, now that this is no longer using DCWorkflow.

This is required with ERP5JS, where every save call render with new data.