This allow user know what is he configuring or accessing

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.

https://github.com/niklasvh/html2canvas/issues/2697#issuecomment-1742732104
https://github.com/niklasvh/html2canvas/issues/2697#issuecomment-1827394925

from 705e0beb (AppliedRule._checkExpand: add parameters to filter objects + better reporting, 2024-06-17)

See merge request !1948

- prepare import_export page to use multiple slapos-master urls (not fully implemented yet)
- update queries, views, forms and gadgets to include slapos-master-url
- drop gadget_erp5_jio, use jio gadget
- minor graph refactoring
- drop obsolete gadgets
- fix and extend sync redirect options

Trigger activeSense on an alarm after an object is indexed.
The idea is to use this script in an interaction workflow to trigger the alarm.

If called multiple times, try to reduce the number of alarm execution.

Prevent potential errors to be returned with 201 status

Follow nexedi/erp5@a659b01c

Same behaviour than File/Image

It is needed if a module contains multiple object's portal types.

- this reverts commit d8119beb.
- risk of allowing JS injection

Fix po_import behavior in Python 2.

Newer versions of polib accept only unicode strings in the
`pofile` function (because they check if they start by the decoded
version of the BOM).
I changed the `data` that is passed to `pofile` to be a unicode
string in Python 2 too. This seems to work locally in my old
version of polib, so that at least the old behavior should be
kept the same.
Co-authored-by: Carlos Ramos Carreño <carlos.ramos@nexedi.com>
Co-authored-by: Jérome Perrin <jerome@nexedi.com>

See merge request nexedi/erp5!1953

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

See merge request nexedi/erp5!1949

to make sure test terminates in case of problems with webdav server