1. 29 Jan, 2023 1 commit
  2. 28 Jan, 2023 1 commit
  3. 26 Jan, 2023 1 commit
  4. 25 Jan, 2023 4 commits
    • Xiaowu Zhang's avatar
      erp5_web_renderjs_ui_test: fix broken tests · ee8ca461
      Xiaowu Zhang authored
      See merge request !1731
      ee8ca461
    • Xiaowu Zhang's avatar
    • Xiaowu Zhang's avatar
      erp5_web_renderjs_ui_test: fix broken tests · 43300d92
      Xiaowu Zhang authored
      cause by !1726
      43300d92
    • Jérome Perrin's avatar
      Compatibility with DateTime >= 3 · fd737b5f
      Jérome Perrin authored
      On the way to Zope 4, the biggest change was DateTime >= 3, which has these main differences:
      
       - `DateTime` instances are new style classes
       - `DateTime.__eq__` now take into the timezone into account
       - `DateTime` supports timezone naive ( https://docs.python.org/3/library/datetime.html#aware-and-naive-objects ) - actually this is since DateTime 2.12 , but since we fully patched the method where the parsing happens, ERP5's patched DateTime never used timezone naive dates.
       - pickles are also different.
      
      These are changes to prepare ERP5 code base to support DateTime >= 3, while keeping compatibility with the previous behavior, this means that we keep patching to keep the same behavior as DateTime 2, so that `DateTime.__eq__` ignores timezone difference and `DateTime` does not support timezone naive dates - these two different behavior seemed to introduce too much breakages, especially in project code, with no immediate benefit for our usages. For now, while ERP5 is still based on Zope 2 / DateTime 2 the fact that DateTime are new style classes has no impact, this will only impact once we switch to Zope 4.
      
      This also change the code to adjust the part where we were depending on implementation details of DateTime and where the details changed on DateTime 3, sometimes exposing higher level API, like the new `timeZoneContext` to use in tests.
      
      
      
      See merge request nexedi/erp5!1593
      fd737b5f
  5. 24 Jan, 2023 3 commits
  6. 23 Jan, 2023 10 commits
  7. 20 Jan, 2023 1 commit
  8. 18 Jan, 2023 5 commits
  9. 17 Jan, 2023 2 commits
  10. 16 Jan, 2023 1 commit
  11. 13 Jan, 2023 4 commits
  12. 12 Jan, 2023 4 commits
  13. 11 Jan, 2023 3 commits
    • Jérome Perrin's avatar
      accounting: only allow validated bank accounts belonging to sections · 5e85b655
      Jérome Perrin authored
      The only check with accounting transactions regarding bank account
      was that the bank account is not invalidated. This makes the
      constraint more strict by checking that the bank account belongs to
      the corresponding entity and also that the bank account is validated.
      
      A few tests needed to be updated to validate the bank accounts. Also
      a legacy sequence test has been removed because it is now covered by
      normal tests.
      5e85b655
    • Jérome Perrin's avatar
    • Jérome Perrin's avatar
      accounting: support passing a person in AccountModule_getBankAccountItemList · 74a00c76
      Jérome Perrin authored
      The parameter is still named `organisation` for "API stability", but
      this parameter can be a person.
      
      This was already used by the fields on accounting transaction for
      source/destination_payment and more or less working already, except
      for the case where the person had a subordination to an organisation
      member of the group, in that case instead of showing the bank accounts
      from the person this was showing the bank accounts from the
      organisation
      74a00c76