- 06 Mar, 2024 26 commits
-
-
Kazuhiko Shiozaki authored
-
Kazuhiko Shiozaki authored
-
Kazuhiko Shiozaki authored
-
Kazuhiko Shiozaki authored
-
Kazuhiko Shiozaki authored
-
Kazuhiko Shiozaki authored
-
Kazuhiko Shiozaki authored
-
Kazuhiko Shiozaki authored
-
Kazuhiko Shiozaki authored
also str representation of unicode character is different.
-
Kazuhiko Shiozaki authored
-
Kazuhiko Shiozaki authored
-
Kazuhiko Shiozaki authored
-
Kazuhiko Shiozaki authored
-
Kazuhiko Shiozaki authored
-
Kazuhiko Shiozaki authored
-
Kazuhiko Shiozaki authored
-
Kazuhiko Shiozaki authored
-
Kazuhiko Shiozaki authored
-
Kazuhiko Shiozaki authored
-
Kazuhiko Shiozaki authored
-
Kazuhiko Shiozaki authored
-
Arnaud Fontaine authored
-
Kazuhiko Shiozaki authored
-
Jérome Perrin authored
-
Jérome Perrin authored
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)
-
Jérome Perrin authored
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.
-
- 05 Mar, 2024 14 commits
-
-
Jérome Perrin authored
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>
-
Jérome Perrin authored
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.
-
Jérome Perrin authored
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>
-
Jérome Perrin authored
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 )
-
Jérome Perrin authored
We have DublinCore.short_title and SimpleItem.short_title, make the two use the same default value for consistency.
-
Kazuhiko Shiozaki authored
-
Kazuhiko Shiozaki authored
-
Jérome Perrin authored
-
Jérome Perrin authored
This is what happens with PYTHONHASHSEED=0, but when set to something random, the order was not guaranteed.
-
Jérome Perrin authored
-
Jérome Perrin authored
-
Jérome Perrin authored
Revealed by erp5_accounting_ui_test:testERP5CurrencyExchangeLine PYTHONHASHSEED: 438 on py2 Co-authored-by: Kazuhiko SHIOZAKI <kazuhiko@nexedi.com>
-
Jérome Perrin authored
When searching for something like for example "A AND B", make sure that the AND complex query contains query for ["A", "B"], not ["B", "A"]. This is probably always equivalent in generated SQL, but this makes testing easier. Revealed by testSQLCatalog.TestSQLCatalog with PYTHONHASHSEED 279 on py2
-
Jérome Perrin authored
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 )
-