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

These are simple report/exports, they work fine with ERP5JS

Since a long time python unittest provides good assertions and we don't need to
build out own.

If a Credential Request/Recovery can not be accepted, the alarm should not
retry again and again.

We use an hasActivity test before trying to accept to prevent causing multiple
failing activities, if it already failed once, no need to retry more,
CMFActivity built-in retry mechanism is enough.

- Use ³ instead of the HTML entity form, ERP5JS does not allow HTML in field names
- Make Component_view uses Base_viewPDMFieldLibrary, like Product_view
- Add the proper description of this in field library
- Resource_viewFieldLibrary/my_base_volume is kept, for compatibility (not sure it's needed)
- Adjust ERP5Site_checkNamingConventions to allow m³, not m&179;
- Update all translations

We sometimes used "Invalid search criteria", sometimes "Invalid Search
Criteria". Unify to use "Invalid Search Criteria" everywhere

See merge request !1177

See merge request !1182

    The separation aims to reduce the dependency required to use the macros, where:

       * erp5_web_renderjs_ui_test contains the tests and the dependencies to run the tests
       * erp5_web_renderjs_ui_test_core contains the reusable macros, that can be used on other projects to write their own tests.

This is a first prototype showing how a site rendering can be modified
on the style with a renderJS gadget (to remove, add, modify current page
elements).

The navigation is automatically handle by the javascript (with the
pushState API), which really speed up the navigation on powerless
machine (like Pinebook Pro).

Until now, a reset was performed even though ZODB Components were not created or
replaced. Introduce a new installation hook to avoid those useless resets.

When installing bootstrap bt5s, erp5_base, erp5_simulation: 33 => 12 resets.

Improve consistency with document view

The changes from !1158 were not so good in ERP5JS, it was good to have the action here:

![stock browser dialog showing Stock as a view action](/uploads/0e9495858295016926da484b6c5fa68f/image.png)

and not under "Exports", because this is not an export, it's an interactive report.

Also, the "Stock" button is not easy to understand, this is not an action, so we use only an update button now:


![stock browser dialog with only an update action, no action](/uploads/71f40b3e2e951f3c95f7ff885dd91090/image.png)

Also, the action button in movement history was confusing, it's not a button where user have to click. It was like this, with a confusing button (but this button was sometimes useful, because with this button we can go back to stock browser):

![movement history before](/uploads/75450d7fbfe1f208ca17e14b22059b38/image.png)

Now it's like this, the button is not here, but since the action is now listed in Views, it's easy to go back to stock browser:

![movement history after](/uploads/d66d28f1fc66b69b84baba6d88574afc/image.png)

See merge request !1179

Since 5eb06085 (erp5_web_renderjs_ui: do not display submit and cancel if action is empty in form_dialog., 2020-06-10) ERP5JS does not display submit button, this continues in this direction to:

 - Apply the same possibility in xhtml_style to not show a submit button when there's no action. In xhtml_style we show the cancel button using the same rules as everywhere else.
 - Fix error in ERP5JS for dialogs with only an update action but no action.

See merge request !1181

Change login button to comply with Google's branding guidelines.

Add support for google login in ERP5JS.


See merge request !1166

See merge request !1171

There's nothing wrong in having more than one listbox in a dialog

The initial intention was to "disallow invalidated", without forcing users to
validate everything, but it was probably a mistake, if users don't need to
validate then validation workflow would be a bit meaningless.

This is made after an incident where a user mistakenly cloned a validated
currency and the cloned currency was available everywhere in the system.

Change to not return draft currencies by default and also change so that all
items are tuple, for consistency. That should have no impact and is a bit
easier for the test.

Also adjust accounting_ui_test, we need to validate currencies for the tests
and clear cache if we validated some (but we don't need to clear cache if we
validate accounts, because account caches is more clever and does not need to
clear all cache)

also, we don't send passwords by email

Since the workflow is linear, make sure the states and transitions are
sorted in the listboxs in same order as workflow, this makes
re-configuring the workflow a bit easier.