1. 21 Mar, 2024 2 commits
    • Rafael Monnerat's avatar
      erp5_xhtml_style: Dont jump to workflow manage main · 9805e260
      Rafael Monnerat authored
         Workflows now are viable from ERP5 UI, so redirect to /view instead
      9805e260
    • Jérome Perrin's avatar
      Fix code depending on python2 __hash__ · 0ed7ff48
      Jérome Perrin authored
      With python2, iterating on a dictionary or a set always produces the same result,
      although this is not a documented behavior. On python3 this is not the case,
      because the hashing algorithm is random by default, which can also be set using [`PYTHONHASHSEED`](https://docs.python.org/3/using/cmdline.html#envvar-PYTHONHASHSEED). On SlapOS, this is done with nexedi/slapos!1535 
      
      This fixes the parts where ERP5 code depends on python2 order, mostly tests, but also places
      where we iterate on a dictionary or set. Most of the time, the fix has been to sort so that
      the order is deterministic regardless of the hash algorithm randomization, but sometimes we
      had to extend a bit the configuration where the order was really important. We did this after
      discovering the problematic areas by running tests multiple times with different hash randomization
      seeds. It's not impossible that changing from "default python2 order" to "sorted" reveals some
      more problems in custom configurations, but this would mean that the configuration must be 
      adjusted to use explicit order instead of being lucky with the default python2 order.
      
      The main pattern was the use of `edit` method which edits properties in an order that is a bit
      constrained with the `edit_order` mechanism, because some properties depend on other properties,
      so it's important to set them in order. This extends a bit the `edit_order` mechanism to specify
      more properties that were edited in the right order with `PYTHONHASHSEED=0` by chance.
      
      This also extends delivery builders to edit properties in order defined in the equivalence tester,
      most equivalence tester were already properly configured, except the `start_date` and `stop_date`
      from delivery level movement groups. That probably only matters for some specific test assertions,
      but in practice this was visible in a lot of failing tests.
      
      Some visible changes are that:
       - workflows are now sorted alphabetically on history tab
       - properties are now sorted alphabetically on the diff view of history tab
       - business templates are installed in the order of dependencies and in alphabetic order when they
        are not constrained.
      
      See merge request nexedi/erp5!1882
      0ed7ff48
  2. 19 Mar, 2024 13 commits
  3. 18 Mar, 2024 7 commits
  4. 13 Mar, 2024 5 commits
  5. 11 Mar, 2024 5 commits
  6. 08 Mar, 2024 3 commits
  7. 07 Mar, 2024 2 commits
  8. 06 Mar, 2024 2 commits
    • Léo-Paul Géneau's avatar
      erp5_officejs_drone_simulator: add timestamp to position · 48a82c22
      Léo-Paul Géneau authored
      See merge request !1897
      
      * change property drone_dict into function getDroneDict
      * add timestamp to getCurrentPosition return value
      * add timestamp to drone_info
      48a82c22
    • Jérome Perrin's avatar
      payroll_l10n_fr: fix for DSN sorts · a64a94e8
      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.
      a64a94e8
  9. 05 Mar, 2024 1 commit
    • Jérome Perrin's avatar
      *: refactor edit_order of Base._edit · 6c2bffed
      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's avatarKazuhiko SHIOZAKI <kazuhiko@nexedi.com>
      6c2bffed