1. 30 Jan, 2023 4 commits
  2. 29 Jan, 2023 1 commit
  3. 28 Jan, 2023 1 commit
  4. 26 Jan, 2023 1 commit
  5. 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
      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
  6. 24 Jan, 2023 3 commits
  7. 23 Jan, 2023 10 commits
  8. 20 Jan, 2023 1 commit
  9. 18 Jan, 2023 5 commits
  10. 17 Jan, 2023 2 commits
  11. 16 Jan, 2023 1 commit
  12. 13 Jan, 2023 4 commits
  13. 12 Jan, 2023 3 commits
    • Jérome Perrin's avatar
      accounting: keep "??? (value)" to display invalid bank account · 784c5ab2
      Jérome Perrin authored
      The changes from ae15e7e1 (accounting: show the context when
      showing invalid bank accounts, 2022-12-21) were a regression because
      with the previous behaviour, by just looking at the transactions,
      users could see with the ??? that something was wrong with the bank
      account. After these changes they had to open the select element.
      
      This restore somehow the previous behaviour by displaying the label
      with ??? marker, but since we have the label, we display the
      label (bank account reference) instead of the value (the relative URL)
      784c5ab2
    • Jérome Perrin's avatar
      payment_mean_sepa: prevent error with payment transaction for persons · ab137095
      Jérome Perrin authored
      This was working only with Organisations
      ab137095
    • Jérome Perrin's avatar
      Improve bank accounts selection on accounting transactions · b5a6ec60
      Jérome Perrin authored
      Fix small problems displaying bank accounts on accounting transactions and be more strict during validation:
       - bank account must be validated
       - bank account must belong to the section
      
      The latter was a problem for scenarios like this:
       - create transaction for supplier 1 with supplier 1 bank account
       - clone transaction
       - change to supplier 2
      the bank account remains as supplier 1 bank account, although it became an invoice from supplier 2.
      The transaction could be validated as long as the bank account is not invalidated
      
      See merge request nexedi/erp5!1713
      b5a6ec60