1. 16 Feb, 2023 2 commits
  2. 15 Feb, 2023 2 commits
  3. 14 Feb, 2023 1 commit
    • Jérome Perrin's avatar
      oauth2_resource: fix property id · 55b855c6
      Jérome Perrin authored
      This object was not exported with its actual ID, reindexing cause
      warnings in the log, like this:
      
          2023-02-13 08:13:47,169 WARNING CMFActivity Message dropped (no object found at path ('', 'erp5', 'portal_property_sheets', 'OAuth2AuthorisationClientConnector', 'usable_as_default_property'))
          Traceback (most recent call last):
            File "./parts/erp5/product/CMFActivity/ActivityTool.py", line 282, in getObject
              obj = self._getObject(activity_tool)
            File "./parts/erp5/product/CMFActivity/ActivityTool.py", line 276, in _getObject
              obj = obj[id]
            File "./eggs/Zope2-2.13.30-py2.7.egg/OFS/ObjectManager.py", line 783, in __getitem__
              raise KeyError, key
          KeyError: 'usable_as_default_property'
      55b855c6
  4. 13 Feb, 2023 1 commit
  5. 10 Feb, 2023 3 commits
  6. 08 Feb, 2023 3 commits
  7. 06 Feb, 2023 1 commit
  8. 04 Feb, 2023 1 commit
    • Jérome Perrin's avatar
      credential: stop using deprecated property for email · 149fdd1d
      Jérome Perrin authored
      In 44e0b22f (Move to new API, detailed properties take precedence,
      2011-09-09) we introduce a new data model for coordinates, in the case
      of emails, we have "url_string" fro the "detailed" form and
      "coordinate_text", for the "store what user entered" form.
      
      In some places of erp5_credential, we use setDefaultEmailText, which
      calls Coordinate.setText which uses the deprecated Coordinate.fromText,
      which sets the same value for "url_string" and "coordinate_text", which
      seems a questionable behavior, because the data is saved twice and
      some code might be using the wrong property.
      
      This changes every usage to the new coordinate_text property
      149fdd1d
  9. 03 Feb, 2023 9 commits
  10. 02 Feb, 2023 1 commit
  11. 30 Jan, 2023 9 commits
  12. 29 Jan, 2023 1 commit
  13. 28 Jan, 2023 1 commit
  14. 26 Jan, 2023 1 commit
  15. 25 Jan, 2023 4 commits
    • Xiaowu Zhang's avatar
      erp5_web_renderjs_ui_test: fix broken tests · ee8ca461
      Xiaowu Zhang authored
      See merge request nexedi/erp5!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