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

Graph tooltip destruction was fixed with commit https://github.com/odoo/odoo/commit/86252428846607cd5f4b18cef8de49a8cd0b151a#diff-5de06eee7a2eeae066aa1348a1528fe9L100.
Unfortunately, the commit supposed that the 'display_' methods always
returned a graph, which is wrong.

opw-773759

The google 'video.google.com/get_player' URL seems to be deprecated so
the URL used by website_slides had to be updated.

Also when switching a slide URL from a drive URL to a youtube URL, odoo
still kept thinking it was a drive URL.

opw-773984

If the Odoo server runs with its sources read-only
for itself, this is not possible for the server
to touch the files contained in the assets.

In such a case, instead of touching the file,
we alter the attachment checksum, to simulate
a change within the modified date.

However, in such a case, we can only test that the
bundle is well generated again.
We can no longer check the change of version and modified date,
since the modified date of the files have not changed,
and therefore the checksum (which is based on the files
modified date, among others) neither.

Since the revision
5e3de76f

The `::text` is included within the `unaccent` call
The expession tests have never been changed according
to this change of behavior in the building of the unaccented
queries. This has never been detected by runbot because
you need to start the Odoo server with the option
`--unaccent`
and to create the database with the unaccent extension
`CREATE EXTENSION unaccent`
to be able to fail the former tests,
and this is not the case on runbot.

Backport & adapt commits afd4b68a & 27787265

As google starts to refuse to answer to our geocode requests, we need
to mock results in tests.

On chrome only, the translate icon was over the <input/> element but
below the <input/> text... this commit fixes this by forcing
relative positioning on the icon so that it is always rendered after
the <input/> (which seems to solve the chrome bug).

The lang in the context can be None or False
To avoid similar error as revealed at ede29e6d, correctly retrieve the context

There is a double-check (on client and on server) to prevent the user to
upload a >25 MB document. The client checks the actual file size while
the server guesses it from the total received payload. This server guess
is wrong as the extra payload is quite huge (5-10MB). Now the server
checks the real file size as it should have from the beginning.

Before this commit, if a reminder was created and the dates being
formatted contained unicode characters the whole thing would break
because python + unicode is hard.

Example: Japanese with Asia/Tokyo timezone and creating reminders
of 1 day, see support ticket 771674

The signature of the function _compute_quantity is
 _compute_quantity(self, qty, to_unit, round=True, rounding_method='UP')
With courtesy of @PierreFaniel

Closes #19682

opw:774104

opw:774104

Before this commit, the track description and partner biography were
not able to be edited after proposal.

While the currency code of the Algerian Dinar is DZD, (latin) currency symbol is DA.

Fine tuning of this commit: ce2d00f3

opw:767224

Purpose
=======

Currently, if we want to print an expense report that has several currencies in its expense lines, the total amount is hidden on the report. Otherwise, it is simply summed.

That could lead to confusing uses cases. Example.
1 expense line of 92 dollars.
1 expense report expressed in euros.

In the report we will have
- 1 line of 92 dollars
- Total amount: 92 euros

Which is obviously wrong.

Specification
=============

Always display the amount + Compute the amount in the expense report currency, by converting the amount with the rate at the day the expense has been made.

[FIX] account, point_of_sale, purchase, sale, website_sale: correctly set included tax in multi-company

A product can have multiple included taxes (i.e. one by company).
When computing the product price with function _fix_tax_included_price,
only the taxes of the company should be considered. Otherwise it could remove
all the included taxes of all companies.

ps: When no company is set on the SO, all the taxes visible from the company of the user
are set for the product of the line. Same behavior as in _compute_tax_id.

Closes #19566

opw:770464

Changing the address type of a contact in the "Contact & Addresses" tab
could in some instance lead to a dead image (just visually, saving it
would not change it) because the image is set to something like
"data:image/png;base64,5.23 Kb" because of a combination of kanba/form
x2many view, onchange, the differences of field present.

In 9.0 this did not happen because the image was not a field in the form
view corresponding to a contact of the kanban contacts view.

In saa-15 thanks to bf264450 the image_small is different than image in
the kanban view and this got us out of the issue.

In saas-16 it is solved even further because new views only load missing
fields.

This commit just get out of the issue by preventing an update of the
records field (with bin_size which caused the issue of the image) when
opening the modal form view of a contact's contact.

Ideally we should solve this more deeply but this is dangerous code to
change (eg. removing the bin_size would solve it but this was done for a
reason and could affect performances) and the effect is just visual in a
very particular set of factors (if we save the form after the image is
dead, the previous image reappeared).

opw-765952
closes #19491

- Create a product with:
  Product UoM: kg
  Purchase UoM: lb(s)
  Tracking: By lot(s)
- Purchase 100 lb(s), validate and receive picking (set lot 001)
- Return the picking
- Set the lot

The quantity to do is 45.36 instead of 100.

We make sure to convert the quant UoM (=Product UoM) into the
appropriate UoM.

opw-771930

Modifiers (eg. required, readonly, ... on a field) are computed after a
record has been changed. When loading a record they could be computed
based on x2many in a inconsistent state.

eg. on res.partner form, by defaut the email is required depending on:
        [('user_ids','!=', [])]
    but when switching from one record to another this was computed
    wrongly based on the difference between the two records.

This change make the x2many when loading a record ready to be used as
soon as it is set to solve this issue.

forward-port: not needed after saas-15 thanks to framework views rewrite

fix #18239
opw-749483
closes #18815

The method _procure_orderpoint_confirm in stock/procurement is calld in sudo() by run_scheduler.
Even if this method receives the company as parameter, the company is not enforced for all
the processes trigerred into the method. i.e. If a PO is generated by the run of the procurements
the sequence used is the one of the admin's company and not the one for the given company.
To enforce the company to use, we force the company into the context if it's not the same as
the user's company.

opw:771851