1. 02 Jul, 2024 5 commits
    • Romain Courteaud's avatar
    • Romain Courteaud's avatar
      erp5_officejs_support_request_ui_test: wait for... · 650ec5cf
      Romain Courteaud authored
      erp5_officejs_support_request_ui_test: wait for gadget_erp5_page_support_request_fast_view_dialog to refresh the select field
      650ec5cf
    • Vincent Pelletier's avatar
      Products.CMFActivity: Distribute all activities pending distribution · 4cbc4eea
      Vincent Pelletier authored
      Activity distribution (actually: validation) is fundamentally a bottleneck
      of the current CMFActivity design: there can be only one distribution/
      validation node, and it must check every single activity which express a
      dependency over any activity, until these dependencies are satisfied.
      As a result, distribution/validation is in the critical path between an
      activity being spawned and it being executed, and this work cannot be
      parallelised. So care should be taken to waste as little time as possible,
      in order to reduce the activity execution latency.
      
      Before this change, CMFActivity would distribute at most 1000 activities
      (MAX_VALIDATED_LIMIT) per queue per timerserver wake-up.
      In a typical ERP5 setup, timerserver ticks once per second, which means
      CMFActivity was unable to validate more than 1000 activities per second
      per queue. Maybe there are more activities which are possible to validate
      but still the code was forcing the node to sleep until the next wake-up,
      which is a tremendous waste of time.
      
      This change fixes that issue by having ActivityTool.distribute keep looping
      until there has been an iteration over all activity queues which
      simultaneously did not find any activity they could validate. This lets
      Zope yield CPU control when it would be better spent processing activities
      (those which are preventing the validation of any activities remaining to
      validate) without imposing a maximum effective validation-per-second
      hard limit.
      4cbc4eea
    • Vincent Pelletier's avatar
      Products.CMFActivity.SQLBase: Always commit before returning · 966fb6a0
      Vincent Pelletier authored
      Committing serves two purposes:
      - obviously: it makes any transactional data change persistent
      - less obviously: it releases the database transactional snapshot taken by
        any previously issued query, allowing that snapshot and all snapshots
        after it to be also freed (ex: garbage collecting the data records that
        no other transaction can see)
      In the current state of the code flow, this does not change much: after
      this method returns the code flow should quickly hit a commit anyway,
      either in dequeueMessage or before handing control back to timerserver,
      thereby ending the Zope-initiated transaction.
      But this will not be true in a future version of the code.
      966fb6a0
    • Vincent Pelletier's avatar
      Products.CMFActivity: Inverse dequeueMessage return value · 02791ba1
      Vincent Pelletier authored
      dequeueMessage used to return False when something was done, and True
      otherwise. The only caller which uses that value then reverses it, causing
      a double-negative which makes the code confusing to read.
      Inverse the meaning of the return value, getting rid of this double-
      negation.
      02791ba1
  2. 01 Jul, 2024 3 commits
  3. 28 Jun, 2024 1 commit
  4. 27 Jun, 2024 5 commits
  5. 26 Jun, 2024 2 commits
  6. 25 Jun, 2024 2 commits
  7. 24 Jun, 2024 1 commit
  8. 20 Jun, 2024 1 commit
  9. 19 Jun, 2024 4 commits
  10. 18 Jun, 2024 3 commits
  11. 17 Jun, 2024 1 commit
  12. 11 Jun, 2024 2 commits
  13. 09 Jun, 2024 2 commits
    • Jérome Perrin's avatar
      d885e20e
    • Jérome Perrin's avatar
      oauth_google_login: reimplement with oauthlib/requests · c3488a67
      Jérome Perrin authored
      Because the librairies used here were never ported to python3.
      
      Notable changes:
      
        - ERP5Site_createGoogleUserToOAuth is dropped
        - internal API changed radically, so customizations made by overriding
          scripts are broken.
        - the core logic is now implemented in a connector class (still in
          portal_oauth for simplicity, but it would be simpler to move it to
          portal_web_services)
      
      No changes required in the google console, the redirect uri is still
      ERP5Site_receiveGoogleCallback
      c3488a67
  14. 06 Jun, 2024 3 commits
  15. 05 Jun, 2024 5 commits