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.

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. (51c8a250ac762ede69e16cbf3afc35e70b08b3bb)

  Raise loudly with message.

2- Disallow any compensation. (3c74ed07bf2fff784a7fad48344fe13a5abd906f)

3- Emit more informative log. (534b2e77ade40bb036c4c041401fabcdad72f5af)

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

Implement related keys for translated relations (like `source__translated__title`) and change content translation to index categories, by also indexing types whose translation is set in Localizer.

See merge request nexedi/erp5!1292

Extend stock report dialog to allow choosing a (simple) valuation method

![stock report dialog screenshot](/uploads/2e0fa7c420954c3f84260605b3a6930e/image.png)

which be displayed in a new column, showing the inventory value for each line

See merge request nexedi/erp5!1203

Changing the language and browsing to another web section require to fully refresh the page.

Now that we are able to search using content translation, we also want
to extend this so that columns like "group__title" can be searchable in listboxs,
but categories are usually translated with `erp5_content`, which was not indexed
in content_translation table.

Extend content translation indexing to also support translations coming from
Localizer catalog make this possible.

The only limitation I could think of is that categories will need to be reindexed
when the messages are modified in catalog.

Translated properties are indexed in content translation table,
so nothing prevent us from using them in related keys. Since in
many places we show to user translated titles in relations, it
makes sense to also support searching and sorting in catalog.

This extends related keys syntax only for the newest syntax, so
related keys like `source__translated__title=X` would allow searching
for document who have a source relation to a document with title X.

Since any properties can be translated, if for example a property
`foo` would exist and be translatable, it would be possible to search
using `source__translated__foo=X`

This is only available when content_translation business template
is installed.

The default value of the field was calling Base_getEditorFieldPreferredTextEditor and returned the preferred text editor, because this script assumes the content type to be text/html by default

Ever since the introduction of X-Balancer-Current-Server in SlapOS
haproxy configuration in:
  commit c7f104fbf1f5948928f5545286afbb94fc39102b
  Author: Cédric Le Ninivin <cedric.leninivin@tiolive.com>
  Date:   Tue May 26 13:27:33 2015 +0200

      erp5_cluster: leave ERP5 set the haproxy cookie

the balancer will overwrite this cookie's value, so do not compare it
to our name: balancer may be calling us a name completely unrelated to
the value getCurrentNode returns.
So simplify this function's logic to only do what the docstring says:
decide when to set and when to unset the balancer cookie, and let the
balancer decide the value.
This resolves cases where Zope would set the cookie over and over on
every request when getCurrentNode and balancer disagree on its value.

- use environment variables to pass SLAPOS_TEST_LOG_DIRECTORY and SLAPOS_TEST_SHARED_PART_LIST, as discussed on nexedi/nxdtest!2
- Fix #20200514-218C705 - [testnode] frontend for log access

See merge request nexedi/erp5!1304

This change to unconditionally create products, to make it more clear
that it's OK for test methods to change the products configuration because
they are reset at the beginning of each tests (they have always been removed
during tear down)

This is used and should not be disabled.

There was an error when clicking this dialog, fix that error instead.

See merge request nexedi/erp5!1301

In ERP5JS when redirecting we can use `portal_status_level` to control the appearance of the notification.

This updates the cases when user action could not be performed to redirect with an error level, so that notification appears in orange, not in green (in ERP5JS - in erp5_xhtml_style this has no effect).

accounting, base, trade were updated

See merge request nexedi/erp5!1303

See merge request nexedi/erp5!1302

so that installed objects are owned by System Processes and we can have faster ownership checking for proxy role scripts.

Portal is the Skinnable object, skin magic belongs there.

Also, modernise it a bit.

testnode use to publish the URL of logs so that Nexedi ERP5 can
display link to "view logs". This URL was an IPv6 URL on a certificate
which does not validate.

Now testnode software release request a shared frontend for these
logs and generate a config file with log_frontend_url set.

testnode now advertise the URL of log using the log frontend url
from config.

Also simplify frontend_url key to manage it using the same way.

SLAPOS_TEST_LOG_DIRECTORY and SLAPOS_TEST_SHARED_PART_LIST have been
introduced recently, they are passed to runTestSuite using the usual
way of running runTestSuite once with --help to inspect supported
arguments and passing the argument only if runTestSuite supports them,
but these arguments are not necessarily heavy to compute and are always
known (unlike for example firefox path which is only known if seleniumrunner
extra software was installed), so simplify all this by passing the
parameters are environment variables.