Based on v9 fix: f6b6eb90

Closes #16217

Done at #16240

When expanding a textarea of an editable list,
by putting a long description for instnace,
with multiple lines,
some elements were put above the textarea,
making the content partially hidden

opw-709894
Closes #16083

On large databases, the orderpoint calculation can fail due to the huge
cache used diring the process.

Instead of using one cursor for the transaction, we create a new cursor
every 100 orderpoints, to limit the cache size and speed up the
performances.

opw-726711
Closes #16158

In case you don't have 'field', the first 'if' will raise a warning.
In this case the second 'if' will crash with:
    "'NoneType' object has no attribute 'store'"

This commit closes #16146
Courtesy of @kmetaxas

A rounding issue was resolved in
ee335933. It however introduced
another issue.

Rounding functions (both round_precision in web.utils and float_round
in openerp.tools) are not perfect due to IEEE floating point
limitations. However both should produce the same output given the
same input. An example: rounding 13.95 to 2 digits yields
13.950000000000001.

The additional rounding introduced in
ee335933 on price lead to issues in
certain cases. One example occurs when applying a 90% discount on a
product costing 13.95. The POS will do the following:

> 13.950000000000001 * 0.09999999999999998
1.3949999999999998
> round_pr(1.3949999999999998, .01)
1.4000000000000001

whereas the backend will do (as eg. in sale.order.line)

>>> 13.95 * 0.09999999999999998
1.3949999999999996
>>> round(1.3949999999999996, 2)
1.3900000000000001

Causing a difference of 0.01.

The core of the issue is that in the backend 13.95 is rounded
differently. When a Float gets written to the database doesn't just
pass through the regular float_round. It passes through
_symbol_set_float which truncates characters exceeding the precision.

This implements the same approach in the POS.

opw-715506
Closes #16119

Before this patch, #15920 was happening. The problem was that calling `render_cell` produced a call to [`record.set(column.id + '__display', value)`][1], which triggers the `change` event, which called `render_record` the first time, which called again `render_cell` and produced the 2nd data fetch.

After this patch, `render_record` is only called if there is some place where to put the result, which does not happen in those situations.

There is still the problem that there is one call to name_get for each many2many widget found in a list view (instead of one per full view rendering), but at least they are not two calls!

[1]: https://github.com/odoo/odoo/blob/5d17749ff47c02294d5ff2ae56bbcef9d082562e/addons/web/static/src/js/view_list.js#L1125

Introduced recently in b2d66d0c

opw-726354
Closes #16068

- Activate the MTO route on SO lines
- Activate the route "Buy" on a Product A without quantity on hand, add
  a supplier
- Create a SO with 2 lines. First line is Product A, second line is
  Product A with route MTO
- Confirm the SO, run the procurement if necessary
- Confirm the PO, receive the products
- On the picking generated from the SO, you should have one line
  "Waiting Availability" (the line not MTO) and one line "Available"
  (the line MTO).
- Click "Recheck Availability". One reserved quant from line 2 is moved
  to line 1.

A trick is to assign first the move with ancestors, so we don't "steal"
the reservation on the other move.

Fixes #15950
opw-725373

The CompoundDomain class allows to regroup several domains with an
implicit "AND"; these domains can be either a string, an array or
another CompoundDomain. A CompoundDomain can then be converted to
an array thanks to pyeval.js.
For example, if a CompoundDomain is initialized with `[A, B]` and
`[C]`, the array conversion gave `[A, B, C]` (which is expected).

However, a hackish method was used with CompoundDomain. If one of the
domain of a CompoundDomain is equal to `["|"]` (an array with the
OR operator in it), the two next subdomains were supposed to be joined
by a OR operator. Indeed, for the case of a CompoundDomain initialized
with `["|"]`, `[A]` and `[B]`, the array conversion gave `["|", A, B]`
(which is expected). However, if initialized with `["|"]`, `[A, B]` and
`[C]`, the array conversion gave `["|", A, B, C]` which is very wrong
as what was expected is `["|", "&", A, B, C]`. The problem is that the
given `[A, B]` contains implicit "&" operators.

This commit fixes the problem by normalizing only if the CompoundDomain
starts with a ["|"] or ["!"] array which is the standard odoo case.
This allows to limit breaking custom code (e.g we want a simple "AND"
of `[A]` and `[B]` to stay `[A, B]`, not become `["&", A, B]`).

The commit also modifies a test so that it checks that the problem is
properly solved.

The many2many_tags_email's internal value change logic fails to process
all its values. It is not concurrency proof either.

The internal value change logic is now replaced by a mutex and deferreds
are used for the partner's form view popups in order to allow concurrent
events.

Fine tuning of this commit: 5761b9a3

opw:716519

When not logged in the webstie on Safari and clicking on "Have a Question? Chat with us",
it creates a mail.channel from get_mail_channel and it also creates a translation.
But with Safari, the accept_languages is set with the value 'fr-fr', and this value was set
in the context as the lang='fr_fr'. So when the translation was created, a bad insert query was
raised in sql because the lang didn't exist in the res.lang table. When a translation is created,
the function _get_languages checked that the language is in the table.
So it was impossible to use the chatter when the user is not logged.

NB: interseting functions to see:

-setup_lang in odoo/http.py
-_dispatch in addons/website/models/ir_http.py
-get_mail_channel in addons/im_livechat/models/im_livechat_channel.py

opw:716519

This adds the hw_screen module which is responsible for receiving
rendered HTML from a POS client and sending it to a running Chromium
browser. This is done by sending Remote Debugging Protocol messages over
a WebSocket provided by Chromium. This allows hw_screen to evaluate
arbitrary JS. This is used to seamlessly (without flickering) update the
browser.

This also includes changes to the POSBox. X, Chromium and some
miscellaneous other programs were added. Functionality was added that
automatically displays a fullscreen, UI-less Chromium browser when the
POSBox starts up. This is accomplished through x_application.sh, which
gets executed only when a display is detected. After the browser starts,
it will display a specific screen until it receives the first order update
from a POS client.
Creates a public controller to be able to display the interface on an external
device not connected to the posbox (e.g. tablet)

Courtesy of JOV, LPE, ODO and MAT

In some cases, the description fails (unknow printer, udev issues,...) and while
the printer works fine, the description fails.

This is a cherry pick of 994d45f4 to 8.0 (as the posbox is built on top of it)

This may happen when a dashboard contain references to deleted actions.

This is a regression of
1cedcf6a
and a following of
9a9720ac

opw-709700

In case an exception (programming, out of memory or any other unexpected
failure), the cron_thread would crash and not recover until server restart.

Issue #15666 was an example of failure.

Courtesy of Nils Hamerlinck

If postgresql database is temporarly down, the cron thread may fail.

The cursor creation fails when trying to connect to the server which leads to
the cron thread to die (uncatched exception) and will not restart when postgres
is back.

Fixes #15666

message_post accepts only one id

CLA signature for igallart done at #15625

Closes #15625

If amount = 1 and the category amount = -1, the sum is 0 and the returned
value was amount instead of zero (`0 or amount`)

Avoid this evalution error by splitting on multiple lines

Closes #15470

The previous code (`parent.field_widget.string`) was returning the untranslated
action name (and why use parent anyway?)

Use the action name instead.

Closes #15207
opw-705938

With a sale order with:
- a stockable product
- the `Create Invoice` policy set to `Before Delivery`

After the quotation validation and the invoice validation,
if the user:
 - cancelled the invoice,
 - then validated it again,
 - then hit `ignore exception` on the sale order
 - then registered the payment on the invoice

The picking of the sale order was not created automatically,
and the sale order was therefore stuck.

Actually, it was just a write trigger that was missing:
The condition for the sale order workflow to go to the next state
is that the `invoiced` boolean is set to True.

It was, when the invoice of the sale order was paid
(after having registered the payment), but since
this is a computed field, not stored, no write operation
was actually performed on the sale order, and the workflow
wasn't "notified" that a change occured for the `invoiced` boolean.

A simple write on the sale order (e.g. in its notes) would
have unblock the situation, though.

This trigger ensures the worfklow to be notified when
the invoice of the sale order is paid, and therefore
when the `invoiced` boolean is set to `True`.

opw-706591

In SQL, if there is no quote around the table/field, the result will
be returned as case insensitive.

This was causing a bug in the kanban view which was not displaying
the records because x_AA_count was named x_aa_count.

Done at #15340