As a matter of fact immediateReindexObject doesn't call reindexObject on the object

buidler: Add tmp fix/workaround on movement order

builder: Use periodicity to determinate start date

builder mixin: Take into account supply date range before create movement

builder: Hackish immediate reindex of order to work for parallel build

builder: use dedicated script to evaluate min stock

builder: autoPlan only if possible

builder: Reference of order line is reference of resource line

builder: include order delay and effective date

builder: fixup add missing part for effective date

builder: Tweak and fix supply builder

builder: Fixup supply builder

builder: immediate reindex delivery on creation

builder: use _edit on delivery to only reindex modification

builder: Supply builder work with period

builder: Supply builder improved

builder: use flow unit for min stock calculation

builder:  Supply Builder Fix future inventory for parts not activated yet

builder: Supply builder do not create movement for resources that won't be consumed in the future

SimulationTool: getNextAlertInventoryDate can look for the lowest invetory inferior to the reference quantity

With recent changes in CMFActivity, getServerAddress is now used
when setting up the site, before the ZServer is started, which means:
- getServerAddress memoized a wrong return value;
- the test didn't fail with --load.

The button "Subscribe/Unsubscribe from Timer Service" does not clearly 
explain the fact that it determines whether or not Alarms are enabled in
ERP5. It is very counter-intuitive to see Alarms on "enabled" in the 
"Configure Alarms" screen and yet not have them being run because the
Alarm Node is not subscribed to the Timer Service.

/reviewed-on nexedi/erp5!539

This fallback seems useless in this context, getClientAddr should be
available.

This test does not need to create an actual user as it just check
plugin extract login & password from request.
This test does not need to install the plugin in PAS, the actual check
instanciate another ERP5DumbHTTPExtractionPlugin.

- no longer needed to have same user id and logins.
- upgrader activate the plugin

This keep the current behavior. Invalidating all logins is also a way to
disable login for this user without having to find all tokens and
invalidate them one by one

for compatibility with login/password

Because this was broken, we took the liberty to introduce a breaking
change to fix naming, now type based scripts are *_getUserValue and must
return a user document, with a getUserId method returning the user id.

Make this plugin also an IAuthenticationPlugin which does all the job of
returning the user id.
It does not really make sense to delegate this to default authenticator.
A side effect is that token can still authenticate users with no
assignments, since tokens are scriptable, if this is a requirement, it
can be implemented in scripts.

also update test:

 - plugin must be enabled for IAuthenticationPlugin
 - check complete authentication sequence, not just extraction
 - update scripts to new names
 - simplify transaction management
 - don't set self.person, it was not used anywhere
 - update _createPerson to reindex, as said in docstring
 - merge all tests in on test component

(because my editor runs python3 pytlint)

/reviewed-on nexedi/erp5!839

benefit is very small and unusable for user

nexedi/erp5@1f254aa7

This is called when checking access permission on objects, which happens
very often. CachingMethod has a hit cost which is too high for this use.
Instead, generate this method as part of the portal type class, removing
all call-time logic.

It is superseded by __self__, which (where applicable) prevents
acquisition and getattr-based traversal, improving performance.
Patch AccessControl.users.BasicUser._check_context to extend this change
to zope code (and simplify it in the process).
Also, make __ac_local_roles__ accesses consistent with other places in
our own code as well as in PAS & AccessControl.

getRoles is called a lot (on every restricted access, so hundreds of times
per transaction), it is definitely not the right place to do extra
computation, especially when their result does not change from one call
to the next (configuration should only change on process restart, so not
during a transaction - and even if it someday did, it should be fine to
wait for next transaction for it to take effect).
Instead, do the extra work when creating the user (typically once per
transaction).
Also, modernise python syntax (simplifications & style).
Also, reduce code duplication from ERP5Security.ERP5UserFactory.

Simplifies callers, as they then do not have to test for None.
Also, use sort(key=...), which removes the need for internal 2-tuple
wrapping & unwrapping of all result entries.
Also, coding style (helps line-based profiling readability) & better
naming.

Include worklist parameter generation in the scope of existing cache.
Otherwise, it will be generated in pure loss if it is followed by a cache
hit. Most of WorkflowTool change is just indentation change.

Also, do some minor optimisations/simplifications in patchess.DCWorkflow.
Some comments:
- Guard_checkWithoutRoles return value is evaluated as a boolean, so no
  need to cast to int before returning based on boolean evaluation...
- DCWorkflowDefinition.worklists is always true, even when empty.
- Listing portal types per workflow requires checking all workflows, so
  build the whole mapping and cache it instead of caching for each workflow
  type individually (many more cache hits, fewer redundant computations)
- getVarMatch is expensive just for a fallback and a wrap, bypass it to
  reduce redundant work.

Backward-compatibility path does not need to be fast. Optimise for sane
folders.

This improves performance when unset protected properties are being
accessed.

In contrary to the ParentDeliveryPropertyMovementGroup for property, it has
never actually checked the parent Delivery but the current one.

This also avoids KeyError exceptions when Activities have already been processed
in the meantime.