If user group are recalculated before changing the workflow state, it will only return the same security group
See nexedi/erp5@c00c3636

Prevent generating wrong urls for now

romain_dev: forum

romain_dev: forum use html viewer

romain_dev: forum improve post rendering

romain_dev: thread reader use page language inqtead of local

romain_dev: forum set expected link on the listbox cells

romain_dev: thread fixup

romain_dev: thread use line separator instead of background color

romain_dev: thread paginate

romain_dev: forum link to last page

romain_dev: thread simplify conf from erp5form

romain_dev: forum attachment

romain_dev: thread force white background

This reverts commit e50d05af.

Do not access form submission REQUEST from the listbox list method,
as it is rendered asynchronously in ERP5JS

Allow edition in the new UI

This make everything slow as hell and prevent to quickly save.

Example: <h2 class="foo">bar</h2> => <h3 class="foo">bar</h3>

erp5_web_renderjs_ui: keep previous focus color

Change max age to 1 hour and 1 day

erp5_officejs_support_request_ui_test: wait for gadget_erp5_page_support_request_fast_view_dialog to refresh the select field

We may want to set autocomplete 'off' or whatever other value

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.

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.

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.