The user can be present from diferent logins, password tool only works with ERP5LoginUserMager
  users.

Mixed commit:

  43b1ae1b
  2f05fe1b

Returning true allows to add movements to existing one, and this group shall
always separate them.

uid is used internally during recursive calls and using uid can lead to
traverse all lines of catalog.

Note: Generic code shall have no constraints at all.

Conflicts:

	bt5/erp5_accounting/bt/revision

If 2 lines have the same effective date (catalog has a 1 second precision),
always return the validate and open first.

Commit: 02d06501

Changes applied from history:

http://git.erp5.org/gitweb/erp5.git/history/refs/heads/interaction-drop:/product/ERP5/Document/SubscriptionItem.py?js=1

Original commit from : Lukasz Nowak <luke@nexedi.com>
                       3e45ec35

From Lukasz Nowak:

1- Compensation is undesired. (51c8a250)

  Raise loudly with message.

2- Disallow any compensation. (3c74ed07)

3- Emit more informative log. (534b2e77)

Also minimise activity hurricane by calling expand directly.

Open Orders are searched using indexation timestamp, which allows to see them
in "windows", and does not repeat expand if not needed.

Generate activities and allow to pass the tag. Use search and activate
everywhere which will allow to walk through objects without killing the cluster
even in case of really big documents.

Avoid calling isDivergent which can take few minutes to finish.

causality_state comes from well designed causality workflow, which informs
enough about delivery state. Fetching causality_state property is extremely
fast.

Notes:

Do nothing on 'calculate' instead of disabling *_causality_interaction_workflow as
these interaction workflows do not generate activities directly, and do work
that can't be postponed.

By contrast, 'calculate' transition of delivery_causality_workflow is modified
so that no 'updateCausalityState' activity is created by default.

This commit also update list of method_id which should not call calculate_causality

Conflicts:
	bt5/erp5_crm/bt/revision

For example, if property_sheet "prop" was moved from BT 1 to BT 2 and BT 1 doesn't exist anymore.

Before this commit we have this order:
1.  install BT 2 ("prop" exist and isn't touched)
2. remove BT 1 ("prop" is removed)
=> at the end "prop" doesn't exist anymore

After this commit we have this order:
1. remove BT 1 ("prop" is removed)
2. install BT 2 ("prop" is readded)
=> at the end "prop" exists and is OK

/reviewed-on nexedi/erp5!866

old key was simply "id" so when a container is a VirtualFolder (like Web
Site), container._getOb("id") can return any object with id "id"
including an object outside the container.
    
Change the key to contain PhysicalPath of the container to get only
objects inside the container.
    
This actually fixes installation of some business templates with Web
Site inside.

/reviewed-on !867

1.auto centre for image
2.table line is centered
3. image option is left-margin 3cm under image

Not all lock uses in this code fit context managers, but use them where it
does.

Add 10 seconds timeouts on all blocking calls in this test method, which
should be a thousand times more than required on a slow machine but avoids
completely blocking tests.

Even though it should not raise, a stale lock would be a serious issue.

The intent is to be able to tell that an independently-defined group of
activity nodes may execute given activity, and no other node.
This allows more flexible parallelism control than serialization_tag.

Divide conflict hot-spot to improve write performance: now, conflict risk
will not be proportional to the number of zope processes, but only to the
number of threads within considered process (...because there is no
stable thread name, if there is one day and conflict splitting is needed,
it will be easy to implement: just concatenate that name to node name in
FragmentedLength._map).
Automatically migrate to FragmentedCount on containers larger than 1k
objects (this threshold may evolve).

Provide a way to generate ids on specific documents when they make sense.
Reduces the risk of conflicts that portal_ids's in-ZODB id generator
creates.
Reset generator state on any copy (both copy/pase and clone), but not on
move (cut/paste and setId).

These two classes inherits from two classes implementing CopyContainer API:
- ours, via low-priority bases
- another one, via higher-priority bases, because these classes need
  some non-ERP5 methods to override ERP5 methods.
So after defining these classes, resolve inheritance priority by binding
all CopyContainer methods provided by their ERP5 base class, overriding
the ones provided by their non-ERP5 bases while still allowing their ERP5
base class to override the CopyContainer method.

Allows for safe migration to another id generator, by preventing silent
success of any piece of code still using the former generator, allowing
its detection and resolution before duplicate ids are emitted.
As a consequence, also allows on-demand and partial migration of id
generators.