When cutting with bytes, we might cut in the middle of a multi-bytes
character and later decoding it would cause an error. We could switch
to sending bytes encoded to base64, because the limit would be more
natural to be number of bytes, but just decoding and cutting the string
is easier and in practice not so different.

This bug was revealed by testERP5SyncML.TestERP5SyncML.test_28_PartialData
with PYTHONHASHSEED 872 and test_28_PartialData with PYTHONHASHSEED 238
( on python2 )

The order is used during syncml and if "title" comes before "first_name"
and "last_name", synchronizing persons causes conflicts (because title
of persons is computed from first_name and last_name).
Luckily, sorting properties gives an order that is OK for syncml tests,
so we don't need to invent a new mechanism to control the order of
properties in asXML.

if their content type ended in xml ( such as image/svg+xml ),
TextDocument._convertToBaseFormat was resetting the content type to
application/xml.

When doing something like:

  wp = web_page_module.newContent(
    portal_type='Web Page',
    content_type='image/svg+xml',
    text_content=svg
  )

wp.getContentType() was sometimes 'image/svg+xml' sometimes
'application/xml', depending on the order of edit.

for erp5_web_renderjs_ui_test:testFunctionalRJSPage failures with
PYTHONHASHSEED 347

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

This solves a failure with testBudget, it should only impact test, but
it's probably better to have a deterministic ordering here.

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 probably happened only in the test, but it's safer not to retry
for ever.

With PYTHONHASHSEED=0, editing a document like this:

    foo.edit(
      title="live_test_%s" % new_id,
      reference="live_test_%s" % new_id
    )

only sets the reference, because it sets the reference first and then
when setting title it already has the "live_test_%s" % new_id value (
because title is acquired from reference).

With PYTHONHASHSEED set, the order is not guaranteed and sometimes
title is edited before reference. This is revealed by
testHalJsonStyle.TestERP5Document_getHateoas_mode_search with
PYTHONHASHSEED 465.

Co-authored-by: Kazuhiko SHIOZAKI <kazuhiko@nexedi.com>

otherwise edit is called with both (new) resource_uid and (old) resource_value.

revealed by erp5_web_renderjs_ui_test:testFunctionalRJSDeveloperMode
with PYTHONHASHSEED: 977 on py2

erp5_workflow_test:testWorkflowAndDCWorkflow PYTHONHASHSEED=872 fails
with:

    ValueError: UID mismatch for <Workflow Script at /erp5_portal_7faf002ae74ecbab0dce45c9fca0f5e1/portal_workflow/testing_erp5_interaction_workflow/script_afterValidate>

Using portal_transforms is not deterministic, because we don't have
direct chain from ods to text, so the conversion is two steps, either
ods=>html=>text or ods=>pdf=>text.

This caused problem with hash randomization, revealed by
testDeferredStyle.TestODSDeferredStyle.test_report_method_access_request
with PYTHONHASHSEED=538 on python2. When using PYTHONHASHSEED=0 , this
was using ods=>html=>text and the assertion from the test was OK, but
when using ods=>pdf=>text the test fails because the words are cut at
end of line.

use a valid image in testERP5ImageProcessor, this test evolved and
became a test for ERP5 behavior with broken images.

This indirectly solves a failure with testERP5ImageProcessor
and PYTHONHASHSEED: 805

When we --load, the sql dump is supposed to be up to date, we don't
need to update translation table every time. This is mainly to solve an
issue that it might not be possible to run ERP5Site_updateTranslationTable
at this point, with testUpgradeInstanceWithOldDataFs this script uses
a print statement, which causes a SyntaxError.

Unit test written by Rafael Monnerat.

See commit 3d7d6d5e.

See merge request !1894

* set _game_duration as an unix epoch
* provide timestamp to onStart function
* add max_command_frequency, if direction commands (setTargetCoordinates
  and loiter) are send more often than max frenquency the drone crashes

See merge request !1895

91cc6c4e (ERP5Type/Utils: configure warnings in zopewsgi, 2024-02-16)
was bad, on python2 zope did not start.

    Action on portal_types just invoke updateRoleMapping on all portal types that have
    at least one Role.

    This is useful whever you change way too many roles and you can to ensure that
    everything is updated.

See merge request !1893

This uses `from __future__ import print_function` from "unrestricted" python code.

For restricted python in python scripts, this expects SlapOS to have slapos!1536 .
Running ERP5 with this patch on an old SlapOS software release should probably be OK,
especially because after all we don't have so much critical code using print.

To ease migration of custom project code, PythonCodeUtils was modified so that
when running CodingStyle python scripts are checked with print_function future enabled.

See merge request !1883

  Since the test() method was fixed the comment became irrelevant

Returning true allows to add movements to existing one, and this group shall
always separate them.

See merge request !1891

Rename triggerParachute function into land in DroneManager for
compliance with multicopters APIs.

See merge request !1880

I investigated a case where activities calling an external API were not
retried after the initial failure, when it was caused by
TimeoutReachedError:

https://lab.nexedi.com/nexedi/erp5/-/blob/f41b33cd91348a800db3b95b30efd857f583bcde/bt5/erp5_web_service/MixinTemplateItem/portal_components/mixin.erp5.RESTAPIClientConnectorMixin.py#L142

The interesting thing is that these activities are written in a way that
allow them to be retried (automatically, or manually) without causing
un-intended side effects, like creating twice a document in the external
API. So not having SQLBase retrying them automatically is a pity.

The bug is that the use of TimeoutReachedError here was intended only
for the activities that are aborted by CMFActivity itself, and not for
the userland code that can also use TimeoutReachedError.

This commit removes this special processing, as there is no need to
especially not retry the activities that trigger the CMFActivity
timeout. The max_retry decision should be taken by the calling code, and
not by CMFActivity.