odoo issue: 774361
https://github.com/odoo/odoo/issues/13784

Specifically, the command `(6, 0, ids)` should only unlink/detach the lines
that satisfy to the field's domain.

Test from #18440

opw-756983

- Set up a journal which only accepts SEPA payments
- Import a CAMT file which contains a statement containing:
  No "Ustrd" data
  A "AddtlNtryInf" description longer than 140 characters
- Reconcile the bank statement

A contrain is raised because the communication of the SEPA payment is
longer than 140 characters.

From commit https://github.com/odoo/enterprise/commit/ff84f8b7,
"AddtlNtryInf" is used if "Ustrd" is empty. However, "AddtlNtryInf" and
"Ustrd" do not have the same restrictions. "Ustrd" can have a maximum of
140 characters, while "AddtlNtryInf" can have a maximum of 500
characters.

opw-772009

Closes #19568

In base/res_partner.py, _fields_view_get calls _fields_view_get_address that could calls again
_fields_view_get in case of address_view_id is specified. That leads to issue in base_address_city
because the _fields_view_get_address method will replace two times the city field and then, we get
a view with two city_id fields.

see #16870 for screenshots

-opw: 774206

That function is called when computing related fields in onchange mode.
The new implementation makes a direct access to the cache's implementation.

opw-772303

Closes #17972

Returns apparently lost during salepocalypse, leads to errors when
calling them over XML-RPC (cannot marshal None).

Fixes #19889

Closes #19386

Closes #19915

Closes #19825

Closes #19838

Done at #19516

Done at #19503

Done at #19210

Done at #19189

Currency position of IDR must before symbol

Closes #19178 

It seems to randomly save a bad value into the cache for star_date(time) field.

For already impacted database, it can be easily fixed with a simple update.
  update calendar_event set start_datetime=start, stop_datetime=stop where allday = 'f';
  update calendar_event set start_date=start, stop_date=stop where allday = 't';

Than can cause errors for google synchro.

To use RFC (Mexico) instead of NIF (Spain)

Closes #19142

Before this fix, if a (non-registered) user tried to unsubscribe an
address *not registered*, they'd get an unsub link, click on it, and
get a "Invalid or expired confirmation link." message, usually
wondering what the bloody hell happened.

Provide a clearer message in that case.

Some fields are groupable even though they are not stored (e.g. an inherited
field, by example the 'date' field of 'fleet.vehicle.log.fuel').

Closes #19779

Typo missing 'e'. Algemen --> Algemene.

Closes #19837

Done at #19837

Observed via google sync, for some events being moved around during
sync the stop_datetime ends up being before the start_datetime failing
the sync. Not (explicitly) reading the computed fields from the old
record properly recomputes them during copy.

Underlying issue linked to (stored) computed fields when multiple
fields are computed by the same method *and* the creation provides a
subset of these fields explicitly: depending on the order in
which *recompute* iterates the fields, it's possible that some of the
fields provided explicitly get extracted (from the cache) before
fields not-provided trigger a recomputation (and overwrite) of
computed fields.

In this case `recompute` iterates [start_datetime, start_date,
stop_date, stop_datetime], if `start_datetime` and `stop_datetime` are
provided explicitly to create, first recompute will check for
`start_datetime`, find it in the cache and extract it, then it checks
for `start_date`, does not find it in the cache, calls
`_compute_dates` which writes all four fields, then it extracts the
recomputed `start_datetime`, creating an incoherence: `start_datetime`
is the one from the old event while `stop_datetime` is the one from
the update/computation. This may lead to invisible corruption if the
event is moved forwards (e.g. creates a multi-day event) and triggers
a validation error if the event is moved backwards (stop_datetime is
now before start_datetime).

ping @rco-odoo multi-field computes may need some special handling
with respect to invalidations & sequencing & the like (e.g. check
their caching as a unit or something).

OPW-771886