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`.

- Create an expense sheet
- Line 1 is 500
- Line 2 is -200
- The total is 300 => a payment of 300 is made

When the payment is validated, the expense is not set as paid.

In v10, one expense line = one account move. In order to know if the
expense is paid we check that each account move is completely
reconciled. The account move of 500 is never completely reconciled by
the payment of 300, so the expense stays opened.

This simply cannot be supported in v10, since each expense line is
handled in a separate account move.

opw-740492

Since last version (1.7) of pylint, new errors have been detected.

Related to rev: https://github.com/odoo/odoo/commit/ecac88dcc074b81ede4925a75080e8d2b4975924

The decorator is inconsistent, and actually useless.

opw-740787

XML-RPC can't serialize None, as a result methods callable over RPC
must return something (True, False, an actual value) otherwise an
error is generated when their result is serialized and sent back to
the client. It happens that JSON-RPC has different limitations and can
serialize None, so MRP had multiple button/action methods which could
be called over JSON-RPC but would break when called in XML-RPC for no
reason.

Fix them by returning `True` or result of `write`.

OPW-728844

When adding a field on a model, only the _inherit were checked, not the _inherits.

This commit fixes the following bug:
1. install `sale` (adding the field `sale_order_count` on `res.partner`)
   - field `sale_order_count` is created on `res.partner`
   - the ir.model.field is tagged with module `sale`

2. install `point_of_sale` (adding another field on `res.users`)
   - field `sale_order_count` is created on `res.users`
   - the ir.model.field is tagged with module `point_of_sale`

When installing sale, the model res.partner is returned in the list of impacted
models, on which _create_fields method is called but not res.users.

A direct consequence of this bug is that, the fields translations are in the
wrong module. May fix some uninstallation bugs too.

Closes #16104

In 9.0 the argument pay_journal in function pay_and_reconcile must be an id
but in 10.0, pay_journal must be a recordset with one element. So it was
not possible to call this method by rpc in 10.0

opw:725737

When grouping by day, by month or by year on a field date in kanban view,
it raised a traceback.

opw:727266

As debugging might be enabled during runtime we need to make sure that
the condition does only pass in case start time is defined

Don't check ids with "id is None" statements, as it won't match if id is False. This caused some bugs with MRP when confirming a MO with no calendar defined, if mrp_operations was installed.

Avoid portal user to receive 403 when trying to edit vat code on /my/account
There are no risk to read field in sudo in this case.

opw-740314

Closes #16608

When deleting payment tokens from website, in My account, by clicking
on button "Manage your payment methods", the public user, the user and
the portal user got a 403 error. But when creating a subscription
for a customer with admin user and setting a payment token for
the company of this customer. This payment token could not be deleted
or modified by its users. In a few cases, it's needed to delete or
modify a payment token, for example, when the expiration date of
the payment token is expired.

opw:740169

Closes #16599

As explained in https://stripe.com/docs/checkout#integration-more-runloop
the function handler.open cannot be called in a deferred because it can
block in some browser.

opw:726101

Done at #16600

When a partner has a lot of contacts, the computation of the issue total
takes a lot of time. Indeed, it performs the computation for the
partner, but also for all the children, despite the fact that the amount
is not displayed.

opw-726355

Currently the amounts of all invoices (linked to sale or purchase
journals) is summed regardless of these invoices being bills or
refunds, this means e.g. if you create an invoice for 1000 then a
refund for 500 on this invoice, the dashboard will display an
"awaiting payment" total of 1500 which while technically correct is
not really logical or helpful from a user's POV.

Fix summation to take in account the invoice type (invoice or refund)
and remove refund amount from the total amount.

Intent validated by @lap-odoo, also not ignoring or removing refunds
from count to avoid situations like "0 Awaiting Payments [for] $-1200"
which would be really strange.

OPW-728860

To substract the included tax from the unit price when it's mapped
by a fiscal position in the POS.

To keep the same behavior introduced by this commit odoo@503820a

opw:710437

Courtesy of BizzAppDev

Closes #16588 

Default mail.alias for crm.team are currently recomputed/modified
when *setting* use_leads on the team (type changes from opportunity to
leads), but not the other way around (*unsetting* use_leads doesn't
rollback type to opportunity).

Fix this issue.

Leaves over the issue that *disabling* the global setting doesn't
recompute aliases, which it probably should.

OPW-728690

Use case when it can happens (non deterministic):
- Enable product variant
- Have different stock moves with the product variant
- Click on the stock moves in the section reports
- Switch to pivot view
-> Traceback : can't find path of null

This happens in the js in the function find_path_in_tree,
this function try to find path for children object. There is
a condition root.children[i].path[l] === path[l] (2 strings
comparaison).

With product variant this condition can be overpass when it should
have been triggered. The product path string is represented as follow
[Ref]Name(variants) -> Sometime the variants in the string do not have
the same order and thus the condition is never true and the function
return null instead of the correct root.

This commit corrects the name_get function for product product
in order to always return the variants in the same order.