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

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>

erp5_web_renderjs_ui: keep previous focus color

If user group are recalculated before changing the workflow state, it will only return the same security group
See nexedi/erp5@c00c3636

See merge request !2034

Infinite listbox are listboxes for which the "lines" property is set to 0, meaning the listbox shouldn't try
to paginate results.

This is intentional, and means that no limit should be applied (iow: an infinite
listbox). In this case, the limit parameter in the call to jIO should be set to 0,
not undefined, otherwise the parameter will be dropped in the AJAX request,
and later on be defaulted to 10 by ERP5Document_getHateoas.

If the max number of lines of a listbox was set to 0, meaning "no limit set", then ERP5Document_getHateoas would still return a paginated list of 10 results, 10 being
the default set in the parameters of ERP5Document_getHateoas.

It looks like there is a beginning of support for such case in ERP5Document_getHateoas,
with the appearance of code such as "if limit", but the bug comes from the lack of typing in the JS-jIO-JSON-ERP5's HAL interface. In case of a limit set to 0 in the listbox configuration, ERP5
would receive the string "0" which is a non empty string. It would fail the condition and would
be handled like there is a limit, or of 0 - so no result - or of a default limit chosen by the code.

The script `Base_createCloneDocument` was made to be user-friendly, reporting
nice errors instead of throwing when a problems is detected. These errors are
displayed using the `portal_status_message` parameter of `Base_redirect`, which
looks like a warning on XHTML-style, but appears green with RenderJS.

This commit adds an optional parameter `portal_status_level` to all calls to
`Base_redirect` which are actually errors, so that they also look like a
warning or error (orange background) on RenderJS. The behaviour in XHTML-style
says identical.

/cc @romain @vpelletier

String value raised with `ValueError` had an extra `%s` at the end, hence
raising another error when formatting:

> TypeError: not enough arguments for format string

This commit simply removes the extra formatting character, since I could not
guess what should have been printed here.

The ZSQLMethod was using a wrong table `movement` instead of the `stock` table,
hence throwing errors. This commit makes it use the right table, by adding a
filter on `node_uid`, taking into account the structure of the new table.

/reviewed-by @jerome
/reviewed-on !2030

See merge request nexedi/erp5!2029

See merge request nexedi/erp5!2028

 - follow Zope4 ZMI style guide
 - remove the confusing "Upgrade" button and the associated method
 `manage_refresh` doing nothing
 - use `form-control` and `code` CSS classes for better looking fields

When refresh_token is still valid google's endpoint does not include the
current refresh token in the response when refreshing the token, we need
to keep the current one.
This fixes user logout every one hour.

So that version view works as expected, see b415abbb (dms: add version
view on notification messages, 2024-06-19)

See merge request nexedi/erp5!2011

Fix bugs:
- Fix an acquisition context bug: the user found here would be wrapped in
  the acquisition context of self, and as a result SecurityManager.validate
  may consider the user to be outside of the acquisition path of the
  document being checked (ex: when accessing a module while publishing a
  web section).
- While unusual, there may be multiple users matching a given request,
  which is handled by ZPublisher but was skipped here.

Also:
Document:
- Why this method is needed.
- assumptions made to get simpler code.
Improve performance:
- portal_membership._huntUser looks the user up twice, which is expensive.
  Stop using this method.
- When the request is a fake request (from restrictedTraverse) nothing can
  nor should be done, so bypass the entire logic that case.
- Assorted tiny improvements: do not retrieve security manager twice, avoid
  extraneous local assignments, ...
Improve coding style:
- Stop accessing portal_membership's underware.
- Stop accessing PluggableAuthenticationService's underware.
- Simplify disabled cache support: this is exceedingly rare, optimise for
  when it is enabled.
- Do not hardcode log level, also increase the severity: this really is a
  warning.
- Do not try to decode Basic-auth, this is the job of the user folder.
  This removes duplicated code.