also str representation of unicode character is different.

for same reason as the xhtml_style version, there is no problem with
having more than one listbox, see d2dedca3 (core: remove useless log
in Base_callDialogMethod, 2020-07-03)

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 )