The render is useful to preview content after edit while doing a gadget or on other contexts.

  Since corportate identity has erp5_web as dependency, it cause no harm to move.

The `write` method of the `output` object was being overwritten
in live tests, replacing it to a function that printed both to
the output and to stdout. This was not necessary, as it is
possible to use this function directly. Moreover, the function
code had two flaws:
  - It assumed that output was a particular (StringIO) class.
  This caused a problem during the migration (commit
  80bd30fc).
  - It printed to stdout instead to stderr.
Using the function directly allows `output.write` to be used
inside it, preventing the first flaw. The second flaw has also
been solved.

   * const is handled as enum with a single value automatically
   * patch ensureArraySize to not modify the user input, let the user safely slice by himself.
   * Reorganise patches so it is grouped by prototype

Improvements compared to the previous implementation:
- avoid looking up the user document again, when the PAS plugin already did
  that job
- make it possible to call a single script when multiple sources of groups
  are based on the same documents, avoiding iterating unnecessarily on
  those same documents multiple times
- avoid repeating the same membership value (ex: when a user has multiple
  assignments with a common membership subset)
- avoid resolving the same relation more than once
- do not go from document value to relative URL only to go from relative
  URL back to document value at the next step
- move security group id extraction to unrestricted python, as the security
  overhead was taking a large amount of time
In a security setup with 8 scripts (all Assignment-based), 6 base
categories, and 4 Assignments (all valid), this implementation is 10 times
faster at producing the same group id set as the previous one.

   This prevents loose data and wrong edits.

   XXX update description on a squash to explain better.

This is no longer needed now, maybe since Zope4 or maybe since a patch
in slapos. This option does not exist on python3 and using pylint on
python3 complains about these disable, so we have to remove them on
python2 as well.

See merge request nexedi/erp5!1912

This makes consistent method resolution order with python3 and reveal a
problem that relation field widgets render_pdf was not the expected one
on python3, solve this by defining explicitly the method.

roundDebitCredit does not raise in case of big difference since
696bc0d2 (2009-02-06 yo * Stop raising an exception, even if the
credit is not equal to the debit in a built delivery, in the post
processing script, because the builder may not blindly adopt prevision
when updating existing lines, thus it can be unbalanced., 2009-02-06)

This assertRaises syntax does nothing on python2 and was an error on
python2. Update the test to test the actual behavior

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

by using str on a dict we don't produce consistent results depending
on hash randomization. This was visible with erp5_core_test:testCacheTool
and PYTHONHASHSEED 12 , the cache id generated in
https://lab.nexedi.com/nexedi/erp5/-/blob/a0aa9184d/bt5/erp5_core_test/TestTemplateItem/portal_components/test.erp5.testCacheTool.py#L216-218
was
"('py_script_obj', (60000,), {'result': 'a short value', 'portal_path': ('', 'erp5')})"

and the cache id generated in
https://lab.nexedi.com/nexedi/erp5/-/blob/a0aa9184d/bt5/erp5_core_test/TestTemplateItem/portal_components/test.erp5.testCacheTool.py#L239-241
with same arguments for delete was
 "('py_script_obj', (60000,), {'portal_path': ('', 'erp5'), 'result': 'a short value'})")

nowadays we can use time.sleep in restricted python

in ec835d86 (payroll_l10n_fr: add missing sorts in DSN report, 2024-02-28)
we added sorts so that the report is deterministic when hash randomization
is enabled, but this was not enough, when iterating through employee_ctp
to find the social_contribution_organisation, not all records have a
corporate_registration_code, so we check that it's present before
accessing it.

Also, one `sorted` that was added was incorrect, because the elements
are dict, so they can not be compared on python3.

Instead of overriding the method and adjusting edit order in some class,
define "_default_edit_order" as a class value and use it in Base._edit
as default value when caller do not explicitly pass edit_order.

This was made to keep the default edit order consistent with the order
of edits on python2 for properties where the edit order matters.

This affects mostly scripts, when for example in a script we do:

  delivery.edit(start_date=d, stop_date=d)

on python2 without PYTHONHASHSEED, stop_date is also set, so we keep
this behavior (that is assumed by some tests).

We also change the order of edit for other properties not constraint
by edit_order to edit them in alphabetic order, to have a constant
deterministic behavior.
Co-authored-by: Kazuhiko SHIOZAKI <kazuhiko@nexedi.com>

Because this was using a set, the order in which property sheets were
used when generating classes was not deterministic.
This can make a different if two property sheets define the same
property. This was the case for short_title property, which was defined
with different default values in DublinCore and SimpleItem property
sheets. With this change the behavior is always same when hash
randomization is enabled.

Property sheets can be defined in classes or on the portal type. The
test only covers the case that a property defined on the portal type
must override the same property defined on a class, but the expected
behavior is also that property sheets defined on a class override
property sheets from parent class.

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.
Co-authored-by: Kazuhiko SHIOZAKI <kazuhiko@nexedi.com>

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 )

We have DublinCore.short_title and SimpleItem.short_title, make the two
use the same default value for consistency.

This is what happens with PYTHONHASHSEED=0, but when set to something
random, the order was not guaranteed.

Revealed by erp5_accounting_ui_test:testERP5CurrencyExchangeLine
PYTHONHASHSEED: 438 on py2
Co-authored-by: Kazuhiko SHIOZAKI <kazuhiko@nexedi.com>