and maybe :

ERP5Type/Base: execute workflow interactions in alphabetic order

With a perfect configuration, this should probably does not matter,
because the order of interactions should not be important (if there
are dependencies they should be handled more explicitly), but this
makes the behavior deterministic.

and maybe:

always sort in edit

movement.hasCategory('quantity_unit') was always false, it was a
misunderstanding of hasCategory API. This was working anyway because
of the order of edit (which depends on iteration order of **kw arguments
passed to edit), this was only working when quantity unit was set before
resource.

( this was revealed by test_01_quantity_unit_copied from testInvoice
running on python2 with PYTHONHASHSEED=164 )

This produces stable output that we can assert more easily in the test

When a business template has multiple dependencies, these dependencies
were installed in an order defined by iteration in dictionaries, which
is not deterministic when using a random PYTHONHASHSEED on python2.

As an example, when we have business template "b" depending on "b1" and
"b2", the only guarantee was that "b" would be installed after "b1" and
"b2", but which one of "b1" and "b2" is installed first was undefined,
now it is stable, "b1" should be installed before "b2", because we added
a sort. In practice it should not matter, because if in that example
"b2" really needs to be installed after "b1", then "b2" should declare a
dependency on "b1".

test_resolveBusinessTemplateListDependency was failing on python3
because the order on python3 was different from the one using
PYTHONHASHSEED=0 on python2.

In that case, the order of actions rendering is undefined, we want to
have unique priorities to have deterministic order of actions.

This things (in practice, tests) deterministic

This probably happened only in the test, but it's safer not to retry
for ever.

See merge request nexedi/erp5!1875

See merge request nexedi/erp5!1873

This script has no reason to be an exception to user's title retrieval
permissions.
Non-ERP5 users do not have applicable access control, so handle those
cases specifically. Such users may be:
- since-deleted ERP5 users
- coming from acl_users/zodb_users
Use a generic placeholder when the user is not allowed to see a
transition's actor.

This allows configuring what URLs can be ingested, by default, no URL
can be ingested.

See merge request nexedi/erp5!1871

This makes ERP5JS's datetime field behave same as python when using
TALES expression for "date_only" and other less used field values.

Co-authored-by: Romain Courteaud <romain@nexedi.com>

 - no more "false" string false
 - empty arrays are false

"false" string evaluating as false allowed to use ?editable=false
in the URL to force a page to render as non editable. This was probably
used only in the tests. The support of this was moved to the form page
gadget.

   Include some symbols to allow this script to be more complaint with erp5_authentication_policy, and more common practices of password settings.

   I explicity didnt include string.ponctuation because it introduces some unusual charts that are not commonly found on passwords like brackets, braces, angle brackets...

erp5_officejs_appstore_base: do not use deprecated script ERP5Site_getAuthenticatedMemberPersonValue

Parameter `partial_text_match` added

Fixup 84281a2a

Correct the naming because this takes a zip file content as argument, so
it expects bytes not string

This improves readability when activity_kw, args or kw are big.

Having a form which allows sending emails with arbitrary senders,
recipients, and content, sent using the site's mail setup, is a recipe for
sending spam and destroying one's mail system's reputation.

See merge request nexedi/erp5!1872