1. 04 Jul, 2024 21 commits
  2. 02 Jul, 2024 7 commits
    • Rafael Monnerat's avatar
    • Rafael Monnerat's avatar
      erp5_oauth_[google|facebook]_login: Normalize get*Connector so we can use on login page · 9dd76a3b
      Rafael Monnerat authored
        This is helpfull to display or not the buttons on login page
      9dd76a3b
    • Rafael Monnerat's avatar
      erp5_core: Don't enable login buttons if the connector isnt configured · fc742752
      Rafael Monnerat authored
        If the login button isnt suppose to work, dont display it.
      fc742752
    • Georgios Dagkakis's avatar
      Widget.py: Allow to set autocomplete also for hidden fields · 7feb1a67
      Georgios Dagkakis authored
      We may want to set autocomplete 'off' or whatever other value
      7feb1a67
    • 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
  3. 01 Jul, 2024 3 commits
  4. 28 Jun, 2024 1 commit
  5. 27 Jun, 2024 5 commits
  6. 26 Jun, 2024 2 commits
  7. 25 Jun, 2024 1 commit