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.

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!1885

It was using "Reference" instead of the dedicated term "Currency Code".

Attribute Unicity constraint message was not correctly including the
reference, the error message was always "Another currency with reference
None already exists".

See merge request nexedi/erp5!1877

    Use a form, so we do not have to hardcode the resource.

   Also include a minimal message.

expand always reindex the full simulation tree, even if there is nothing to do.
This is cpu costly.

No need to generate simulation expand error

* copy all aggregate values
* expand source/destination project defined on the open order
* expand source/destination payment
* support Open Order Cell
* if there is no stop_date, block the generation to today

If 2 lines have the same effective date (catalog has a 1 second precision),
always return the validate and open first.

Commit: 02d06501ce38bc24d5d045968a53017d9b96b312

Changes applied from history:

http://git.erp5.org/gitweb/erp5.git/history/refs/heads/interaction-drop:/product/ERP5/Document/SubscriptionItem.py?js=1