Steps to reproduce:

1. Create two products A and B that require a serial number
2. Create a product C with no trcking
3. Create a BOM for a A with two components B an C
4. Create a MO for A with  qty > 1
5. Check availabiltity and produce the first A
6. Record the SN for the first assembly

Bug: When producing the second assembly, it was not possible to
record the SN for the components.

opw:741316

The class attribute `model_cache` refers to model classes, which refer to their
own registry.  This cache potentially keeps all past registries alive!

When multiple clicking fast (and with the server not too fast), we could
end up with an error (eg. "Cannot read property 'controller' of null").

Something has been done previously to improve this when switching
between views in: fc8a4b5e. This commit do something similar to limit
multiple click on kanban records (doing it as in 26f91c42).

opw-705329
closes #16698

Issue: 741582

This bug happens when you click multiple time quickly on 'run scheduler' button
or if you call 'run reordering rules' and then 'run scheduler' rapidly
It could create duplicate PO or MO.

This happens because the run_scheduler function free the lock while it should
not. ProcurementSudo was created with the old cursor that contains the lock and
the record set that search returns also contains this cursor. The run will call the record set with the bad cursor and commit the lock instead of the wanted
behavior.

This commit creates the ProcurementSudo with the new cursor that does not
contains the lock.

Before this commit, when the user modified the dashboard, it was not always visible without refreshing the web client
For example, display the current dashboard, then go to another view and add an extra view in the dashboard, then go back to the dashboard.
The reason is that the dashboard layout is actually stored in the arch of a form view, and that arch is cached by the data manager.

This is why each change to the dashboard arch requires that we clear the cache.

OPW 740739

Closes #16691

Since the account is a mandatory field, we raise an clear error is no
account is defined.

This is necessary when running an automatic reconciliation on the POS.
The POS uses a try/except to avoid any error, but in the case of an SQL
error, the cursor is invalidated, so the transaction fails.

opw-741677

In PostgreSQL, a field of type `integer` must be in the range
-2147483648 to +2147483647. If the user enters a lower or a larger
value, a traceback is thrown.

opw-740286

When the online SO was already confirmed and paid, the button "Accept and pay"
was displayed instead of "View".

opw:728306

When a invoice line is create a default layout_category_sequence was created
with a value of 0, updating the value of layout_category_id.sequence instead
of fetching it.

This operation was very slow on the invoice creation wizard

opw-741517

opw-741077
This commit closes #16616

Fix options not being passed from view declaration to JS
frontend function. If passing option 'no_create': True,
"Create" button was still visible.

Signed corporate contributor license.

- Create a SO of 1000
- Create a down payment of 300, validate
- Create the final invoice

In the partner view, a total of 1600 is displayed as invoiced.

In the case of a down payment, the corresponding invoice line has an
amount with a negative sign. Since the report computes the absolute
value before multiplying by the sign, this information is lost.

The absolute value is not necessary since `price_subtotal_signed`
already includes the correct sign.

opw-741159

This field is not required, in case it is empty, the rename will crash.

opw-741259

The calendar view display records with the start corresponding to the
record field set as `date_start`, and the stop to the record field set
as `date_stop`.

Since ef886aed there some issue when mingling calendar with
`date_start` or `date_stop` date fields and `all_day` unset:

- if user had timezone between UTC+8 and UTC+14, when moving as
  "All day", the record start would be saved on the previous day.

- if used had timezone between UTC-12 and UTC-5, when moving as
  "All day", the record end would get on the following day.

- if the event was moved onto a given time (in the "Day view"), the
  event start would be set to the previous day if it was before midnight
  in UTC time, and the end would be set on the following day if it was
  after UTC 23:59.

The source of the issue was that after ef886aed a datetime was always
sent to the server, so depending on the browser timezone the server
could for example receive '2017-04-27 23:00' instead of '2017-04-28'.

This fix go back to the previous behavior.

fixes #15540
opw-15540
closes #16698

In some email templates of Odoo, the From: field is generated from the
company name. If this name contains an "&" character, this will lead in
an escaping eg; &

Sender header will look like:
From: Machin &amp; Brol <machinbrol@toto.com>

This case is not well handled by email providers like Gmail, that
splits the line on the ";" and considers there are 2 senders, and then
discards the email.

We then fix the templates, waiting for a better fix in master.

To reproduce, see issue #16611.

In the mentioned use case, a line with a quantity of zero is created,
which generates a traceback at invoice validation.

Fixes #16611
opw-741055

The employee of the expense report should be the same than the employee
on expense lines.

opw-740646

In function name_get on model "delivery.carrier", the field name
is taken from "product.template" and the translations were just
available on model "product.product".

The translations for the "product.template" records were not available
in the .pot file because there was no external identifiers created for
the "product.template".

Now when creating the external identifier of a record, all the external
identifiers of the inherits models of this record are also created.
In this way, all the translations will be created.

opw:728682

This reverts commit 75d9674d and revert well 551719a8 which wass done
on mail.mass_mailing instead of mail.template (on which it should not be
done).

This commit revert the change of 551719a8 forward ported in ed0233fb.

The file and feature modified is not present after saas-11.

Mass mailing `mail templates` when selected in a mass mailing are
always used in the english version.

But when another language is involved the edition of mass mailing
`templates` had a number of issue. For example saving the edited english
would only modify the user current language.

These issues are cause because the widget with snippets used for mass
mailing templates edition is not compatible.

Several fixes were proposed, what was choosen finally was to use the
correct widget with the following behavior changes:

- the snippets are not showed anymore in mass mailing templates,
- the current language can be edited and is saved rightly,

The shortcoming this give mass mailing templates can be partly
compensated by:

- editing the template back (if someone want the old behavior),
- duplicating mass mailings which keep the snippets and translations,
- doing a customization to improve the situation

closes #16255
fixes #16165
opw-726746 opw-727232

note: this fix is only needed for 9.0 and saas-11.

When creating a pad before this change these were the steps:

- modify pad URL for new pad URL
- end of record loading

This caused an issue because modifying the record at this point would
mark it as dirty before displaying it (which would result in a erroneous
warning "The record has been modified, your changes will be discarded.
Are you sure you want to leave this page ?").

With this fix:

- modifying the pad URL is done after the record is ready

- deferred have been unified (to remove possible race conditions)

closes #15239
opw-702797

forward port note: this change is needed up to saas-15, over saas-15
only a small part is needed (because x2many views are loaded with the
root view and there is one widget instance per record).

code note: it would be better to modify load_record of form view and
delay `record_loaded` upto after x2many views are loaded, but possible
impacts have been judged too risky so this is done only in pad widget.

When a PoS order is closed, the payment and the sales journal item are
not automatically reconciled. This potentially leaves a lot of
unreconciled entries for a customer, which will appear in his follow-up
report.

This introduces an auto-reconciliation process upon order closing. The
process restricts the reconciliation to an order individually, i.e. we
don't try to cross-reconcile several orders for a customer.

opw-697565

Add missing sudo to allow a user without accounting rights to close a session
and reconcile entries.

Closes #16517

Closes #16640

This fixes the following issue.  Assume a custom field F is created on
`res.partner`.  This field will appear on `res.users` as an inherited field,
and will be reflected in `ir.model.fields` as a 'base' field.  When F is
removed from the parent model, it no longer appears on the child model in
registry, but remains in `ir.model.fields`.

The patch allows the proper removal of the no-longer-inherited field from
`ir.model.fields`.