Do not access form submission REQUEST from the listbox list method,
as it is rendered asynchronously in ERP5JS

This reverts commit 35b2c024.

Allow edition in the new UI

This make everything slow as hell and prevent to quickly save.

Example: <h2 class="foo">bar</h2> => <h3 class="foo">bar</h3>

Only basic fields are supported (no gadgetfield for now).

It follows commit ce233f79

Some fields may use div element without expecting 100% width.
Example: formbox and diff gadget.

Why invent a different way, making it harder to consistently patch
validated_hook ?

For example, allows upgrading a Business Template when an ERP5 Form is
replaced by a PythonScript in a skin folder.

When running on testnode, runUniTest is responsible for picking a free $DISPLAY.
This is implemented by starting Xvfb on a $DISPLAY, waiting a bit and if it is
still running we assume the $DISPLAY was free. But it seems sometimes we don't
wait enough, when testnodes are overloaded.

This implementation is wrong, we could run a command check that X is running,
but as explained in the code command below, xdpyinfo or other tools are
currently not available in test environment. Since we are considering switching
this to seleniumserver (which would take care of running a X Server for us) so
this is OK for now.

there was also another script for internal

This test was clicking on the first item in a non sorted list and then
checking that the text of the selected element was "a2".

Instead, store the text of the first listbox cell in a variable and use
this in check.

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.