Before this patch the registry and cache signaling was only activated
for PreforkServer. In case Odoo was deployed in a multi process/multi
threaded architecture the signaling was not ensured, causing registry
de-synchronisation amongst threaded servers.

Commit bcd4c90a was intendend to make get_file handle uncaught/unserialized exceptions
in the context of a http request

The drawback is that when get_file received a serialized exception (route: /report/download)
the JS modal was empty in that case

This commit handles both the cases

OPW 1848606
closes #24794

The field quantity_done_store had the same label as the field product_uom_qty
on model "stock.move" and there were confusions in the pivot view of
"stock.move".

opw:1841097

open a pos,
change cashier
hit F5

Before this commit, the previous user was set as cashier, forgetting about the change we made
This was because of two things:
- The original fix to do just this use case was pushed in v9.0 as e14ab697
- In v10.0 the commit 475027b9
    (For v11.0: a9caef0e)
    Was intended to update the res.users objects at their loading to ensure that their access rights were loaded too
    But it did this using the wrong condition

After this commit, it reworks fine

OPW 1844006
related #24762

closes #24764

Suppose we have a delta between two datetimes:

    delta = dt1 - dt0

If delta is negative but less than a day, ``delta.days`` returns -1 (which is
compensated by positive seconds).  In order to avoid this surprising effect,
use ``delta.total_seconds()`` to compute the number of days.

In case we define a field like,

<field name="my_domain" widget="char_domain" context="{'active_test': False}"/>

when selecting records the dialog should display all records (as asked by the
context), but it's not the case.

This commit ensure the field context is passed to the selection dialog.

opw-1831902

Consequence of 19878d01

Backport of fb17edd0

The field signup_valid is a non stored computed field based on signup_token.
The cache is filled with prefetched values, so in a loop the field is read from
the cache and not recomputed due to the missing dependency.

opw 1843442

This commits removes a disambiguation on the choices of the 'Adjustment Type' selection as 'in your favor' could be achieved by debitting the 'Collected Tax' account or creditting the 'Paid Tax' accounts (respectively for 'in favor of the Estate'). The choices now refers directly to the journal item where the tax is gonna be copied

Related to https://github.com/odoo/odoo/commit/c58ef14a01f600d75391f2a9c38bb2b30e0e2528
Related to OPW 1826242

Display a slide, enter fullscreen mode
Make the navigation bar appear.

Now, try to push on any button of the nav bar

Before this commit, none of the button work
This is because the fullscreen mode is handled by the browser, and won't let any non-fullscreen
elements be interactive

After this commit, the nav bar is part of the element that are in fullscreen
And the button work

OPW 1839503
closes #24522

We need to fix a problem with the users where someone might get
informations on registrations.

In 9.0, stages of a job position in recruitment are not share by
default, there is a "New" stage and existing stages can be added in the
form view (since 780f46ae).

When creating a job position, the "New" is not working with the given
widget type.

This commit doesn't show stages in the form view until the record is
created.

opw-1839217
closes #24706

Attribute is different for country and continent objects.

If the user configures a default `template_id` for
the `mail.compose.message`,
this template was used by the mass mailing to render the email,
and, among others,
it therefore used the `email_to` of this email template,
to render the recipients,
and it was configured empty or something else than `object.id`,
it did not used the `active_ids` passed in the context to the
`mail.compose.message` `create` call to compute the correct
recipients

To reproduce:
 - In developer mode (?debug)
 - Open the full mail compose message
   e.g. in app sales, open a so, hit new message,
   and hit the button to open the full message composer
 - Set the template to the quotation template is not there already
 - In the debug menu of the dialog, View > Set defaults,
 - Click the radio button to all users, and the default to Use template = ...
 - Then, try to send a mass mailing. It will fail because it cannot
   compute the `email_to` values correctly because the `email_to`
   of the quotation template is empty.

opw-1840287

- Set a specific expense account on an expense product
- Send an email to the expense alias

The specific expense account is not used; a default account is used
instead.

opw-1838174

In firefox, if we have a range on eg.:

  `<input type="file">`

and we tabulate to get to it, we have the range over:

  `<button type="button" tabindex="0">Browse…</button>`

which seems to be a "virtual" element inside the `<input/>` but this
magic element is "Restricted" and causes error such as:

  `Permission denied to access property "nodeName"`

So this fix ignore errors when getting a range from current selection on
keyup.

opw-1819279
closes #24524

Open a pos session with a user A
Change cashier to user B

Make an order with invoice

Before this commit, the salesman of the order was user B
but the salesman on the invoice was A

After this commit, both invoice and order have user B as salesman

OPW 1844175
closes #24642

It seems that in v8 the internal reference (the code) of the product
was displayed in the sales details report of the pos

This commit put that field back on the report

OPW 1844776
closes #24641

Backport of 57f7c681

After reopening the session in the POS by another user,
the cashier was not correctly identified.

Back-port of this commit: a9caef0e

opw:784422

Some IPs (like google-proxy ones) are not bound to a specific country.
Legacy Database used to set country_code to 'EU' for these one. geoip2,
on contrary, does not set the country. Read information from `continent`
attribute in this case.

opw-1844888

The transcoding of a mail (transforming CSS into inline styles on the
element nodes of the mail) used the form:

 property:value;

So when a mail is saved, it would be eg. with `style="property:value;"`
and when it is being edited "property:value" is removed if available via
CSS stylesheet given the structure.

But the sanitize_style (introduced in bfe7aafa) adds an espace before
the value (which is more pretty but was probably not choosen in
transcoding to decrease size of mail):

 property: value;

so the inline style would not be removed when editing possibly causing
conflict with the editor.

With this commit, the sanitize_style doesn't add a space. It could have
been changed in transcoding but the code is already rather slow and we
don't want to use a regex replace or two string replace instead of the
current one string replace.

opw-1841107

The browser may throw an error when a big mail such as one with
hundreds thousands of tags is being transformed to have a style
more compatible with mail clients.

The error would be:
 "Uncaught RangeError: Maximum call stack size exceeded"

This happens in jquery because we hare too many nodes (there is an
ongoing issue at https://github.com./jquery/sizzle/issues/403) so this
commit replace that part by a DFS traversal over DOM nodes.

There was also an issue that not having the option "style-inline" would
still cause some style code to be ran albeit it was intended not to be
solved in 55c7d2d5.

opw-1841107
closes #24550

* Avoid to invalidate the cache if no actual deletion has been
made when recomputing the taxes

* Avoid to create analytic entries to delete them right away
few lines further in the same method:
 - Analytic entries are created at line 903
   - account_invoice.py:751 `move_line_dict['analytic_line_ids'] = [(0, 0, line._get_analytic_line())]`
   - account_invoice.py:840 `iml = inv.invoice_line_move_line_get()`
   - account_invoice.py:886 `line = inv.group_lines(iml, line)`
   - account_invoice.py:894 `'line_ids': line,`
   - account_invoice.py:903 `move = account_move.with_context(ctx_nolang).create(move_vals)`
 - Then, at line 907, they are deleted and others are created again:
   - account_invoice.py:907 `move.post()`
   - account_move.py:130 `move.line_ids.create_analytic_lines()`
   - account_move.py:1258 `self.mapped('analytic_line_ids').unlink()`
   - account_move.py:1262 `self.env['account.analytic.line'].create(vals_line)`
  Deleting these analytic entries indeed implies the invalidation of the cache.
  Besides, generally speaking, we should avoid to waste resources
  by creating/unlinking records without a good reason.

When the reception route of a warehouse company is deleted by the user
e.g. My company, Chicago Receipt in 1 step is deleted,
and then changing the given warehouse `Incoming Shipments`
multiple times
e.g. from `one_step` to `two_steps` multiple time,
the reception route is created again and again and again.

This is because the reception route which is created for the
warehouse is not being assigned to the warehouse
as the `reception_route_id` once newly created.

opw-1836544

Issue: The clean removes too many tags so emails sent do not resemble the
preview.

opw-1841138
opw-1841105

Steps to reproduce the bug:

- Create a SO with 2 lines and confirm it
- Set a Customer reference on the SO with "This is, a ref"
- Deliver it
- Create an invoice from it with all the invoicable lines

Bug: The name of the invoice was: "This is, a ref, This is, a ref"

Expected behavior: The name of the invoice is: "This is, a ref"

opw:1840738

When a record is created in a different language than English, empty
translations are created using the _set_ids method for translatable fields.

l10n_multilang makes the account translatable, an empty translation is created
when the CoA data is processed.

After the CoA installation, l10n_multilang transfer the translations of the
account templates to the related accounts.

No need to create translation terms again, use _set_ids to update the existing
translations.

This will prevent a cause of translation duplication, forbidden in the future by
160d6577

opw-1832071
Closes #24158

The built-in log rotation is *very* unreliable in a multiprocess
context, which can lead to significant data loss (up to hours of log
missing) right after rotation[0][1].

Technically, according to the cookbook even filehandler does not
support multiprocess logging[2].

Either way, we should at the very least warn that logrotate is a Bad
Idea in multi-workers scenario. Ideally we'd just fall back on regular
file/stream logging but that likely could & would break existing
deployments, so maybe implement that for master instead?

Alternatively: implement it properly in multi-worker scenario with
only the "root" process actually logging to whatever output was set
up, and all workers sending stuff to log to it via a queue or network
socket or w/e.

[0]
https://stackoverflow.com/questions/34186774/why-doesnt-timedrotatingfilehandler-work-properly-and-how-to-solve-this-issuer
[1] https://github.com/odoo/odoo/issues/16566
[2] https://docs.python.org/3/howto/logging-cookbook.html#logging-to-a-single-file-from-multiple-processes

Before this commit, we had the following issue with binary widget in a form:

Suppose we have a binary field with filename attribute set. When uploading a
new file 'temp.txt' with content 'Cg==', the displayed value is 'Cg=='. When
the changes are saved, the displayed value becomes 'temp.txt'.

It should always display 'temp.txt', which is what is fixed by this commit.

In addition to fixing this issue, we describe what is the expected displayed
value of a binary field. This is based on whether the attribute filename is
provided, and whether the record is in edit or read-only mode.

Fixes #21630
Closes #24275

Co-authored-by: Nick Booker <nick.booker@opusvl.com>

[FIX] account: use company currency in _compute_matched_percentage in case no currency is set on account.move

When a move or move line is supposed to use the company currency, its currency_id field is empty. _compute_matched_percentage did not take this into account, causing the rounding method to sometimes be called with a precision equal to False, resulting in erronous and weird behavior (0 was considered different from 0, causing a division by zero in the following condition).