If user group are recalculated before changing the workflow state, it will only return the same security group
See nexedi/erp5@c00c3636

Prevent generating wrong urls for now

romain_dev: forum

romain_dev: forum use html viewer

romain_dev: forum improve post rendering

romain_dev: thread reader use page language inqtead of local

romain_dev: forum set expected link on the listbox cells

romain_dev: thread fixup

romain_dev: thread use line separator instead of background color

romain_dev: thread paginate

romain_dev: forum link to last page

romain_dev: thread simplify conf from erp5form

romain_dev: forum attachment

romain_dev: thread force white background

This reverts commit e50d05af.

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

Change max age to 1 hour and 1 day

When trying to use `MemcachedTool` without the `python-memcached` package,
a dummy implementation is supposed to allow installation while giving a
warning when called.

This dummy implementation was broken because it was calling a wrong class,
named `_MemcachedTool`, which did not exist. Instead, `_MemcacheTool` did
exist and was used for the real implementation.

This commit renames `_MemcacheTool` to `_MemcachedTool` to allow dummy
implementation to work.

Fixes an logged error while indexing:

    2024-03-07 23:44:21.997 WARNING CMFActivity Message dropped (no object found at path ('', 'erp5_portal_ec7d28d9ada99a2cad998125d59fc158', 'image_module', 'gadget_officejs_appstore_app_text_editor_icon_text_editor_png'))
    Traceback (most recent call last):
      File "/srv/slapgrid/slappart22/t/eje/soft/de456d85f70e1b1a086396326977c83c/parts/erp5/product/CMFActivity/ActivityTool.py", line 262, in getObject
        obj = self._getObject(activity_tool)
      File "/srv/slapgrid/slappart22/t/eje/soft/de456d85f70e1b1a086396326977c83c/parts/erp5/product/CMFActivity/ActivityTool.py", line 256, in _getObject
        obj = obj[id]
      File "/srv/slapgrid/slappart22/t/eje/soft/de456d85f70e1b1a086396326977c83c/eggs/Zope-4.8.9+slapospatched002-py2.7.egg/OFS/ObjectManager.py", line 843, in __getitem__
        raise KeyError(key)
    KeyError: 'gadget_officejs_appstore_app_text_editor_icon_text_editor_png'

   Workflows now are viable from ERP5 UI, so redirect to /view instead

With python2, iterating on a dictionary or a set always produces the same result,
although this is not a documented behavior. On python3 this is not the case,
because the hashing algorithm is random by default, which can also be set using [`PYTHONHASHSEED`](https://docs.python.org/3/using/cmdline.html#envvar-PYTHONHASHSEED). On SlapOS, this is done with slapos!1535 

This fixes the parts where ERP5 code depends on python2 order, mostly tests, but also places
where we iterate on a dictionary or set. Most of the time, the fix has been to sort so that
the order is deterministic regardless of the hash algorithm randomization, but sometimes we
had to extend a bit the configuration where the order was really important. We did this after
discovering the problematic areas by running tests multiple times with different hash randomization
seeds. It's not impossible that changing from "default python2 order" to "sorted" reveals some
more problems in custom configurations, but this would mean that the configuration must be 
adjusted to use explicit order instead of being lucky with the default python2 order.

The main pattern was the use of `edit` method which edits properties in an order that is a bit
constrained with the `edit_order` mechanism, because some properties depend on other properties,
so it's important to set them in order. This extends a bit the `edit_order` mechanism to specify
more properties that were edited in the right order with `PYTHONHASHSEED=0` by chance.

This also extends delivery builders to edit properties in order defined in the equivalence tester,
most equivalence tester were already properly configured, except the `start_date` and `stop_date`
from delivery level movement groups. That probably only matters for some specific test assertions,
but in practice this was visible in a lot of failing tests.

Some visible changes are that:
 - workflows are now sorted alphabetically on history tab
 - properties are now sorted alphabetically on the diff view of history tab
 - business templates are installed in the order of dependencies and in alphabetic order when they
  are not constrained.

See merge request !1882