Oversight of previous forward-port

Was probably introduced during a forward-port as was correctly changed at 8df0a2a9

Closes #24238

Issue:
Currently, since "product_type" is not set readonly, it is triggering write() of product.product
model when saving a PO having PO line with product_id. And it is failing by throwing access error
for users belonging to purchase "User" group users due to the fact that write() is permissible to
purchase "Manager" group users only.

Solution:
Made the "product_type" related field readonly since it is used in purchase order views domain
with lone purpose to set "received_qty" field non-editable when order line product is of type
stockable/consumable.

task id 1818787

- Portal payement is not respecting the option to save tokens after payments.

When converting UoM, source and destiantion should be in the
same category. For timesheet, the product can be expressed in
Units if uoM is not activated. We don't want crash, but
interprete the timesheet duration in hours (which is has a different
uoM category). To avoid the error, we used the 'raise_if_failure'
parameter.

When converting UoM, the conversion can fail if the source and destination
uoM are not in the same category. By default, and error is raised, but using
a context key, we can receive the initial quantity.
To avoid the context key (which is not used anymore), we prefer use a dedicated
parameter to be more explicit.

In the calendar view there is some mixing of moment with:

- a local date with given timezone
- a UTC date with added timezone manually applied

The setDate function of calendar model sometimes received either of the
two types, and always transforms them to UTC date with added timezone.

This cause eg. the following issues:

- in the minicalendar, if we click on a day (eg. 12) the day highlighed
  will be the one of 12th at midnight with timezone applied. So with a
  negative timezone the 11th would be highlighted in the mini calendar
  (but the 12th would still be the day shown).

- if we change scale (week/day/month) or open calendar or use next or
  previous button: we call `setDate` with a UTC+timezone moment. So each
  time this is done, we get an additional timezone

  eg. when opening the calendar view on the 12th at 5:00 with GMT-0200:
      -> the target date is 12th at 1:00
      -> if we set the day mode: target date is 11th at 23:00
      -> if we set the week mode: target date is 11th at 21:00

With this change we keep target_date and highlight_date as local date so
setDate always receives a local date and jquery-ui DatePicker gets the
date in the expected format.

opw-1831368
closes #24188

Do not allow to change the product on a serial/lot number for a product
which has existing stock moves. Doing so would screw up the traceability
report.

opw-1832452

Odoo 11 is python 3 but the xmlrpc interface works with python 2 too.
The example should probably be migrated to use python 3.
In the meantime specify exactly these examples are python 2 to avoid the
confusion.

Fixes #24232

When creating an invoice with 'Down payment' option for an SO, it should
first consider income account of the 'Deposit Product'. if it does not
have one then it should consider that product category's income account.

Fixes #23100
Task# 1819531

Remove the valuation stat button as we say that from now on, to
understand the current value of a product, you should go through the
valuation ation and its stat button.

We add the valuation at date wizard by re-using the quantity at date
wizard and adding a context key to separate the both.

The same view/action is used when openning the current or at date
valuation, only the `to_date` context key is changed.

For the standard and average cost method, we use `qty_available` at date
and the `product.price.history` table.

For FIFO, the normal way would have been to get the `qty_available` at
date and value this quantity with the more recent IN moves at this date.

But there's two main obstacles preventing to use this solution:
- when editing a done move to change the quantity, the change is
  reflected at the date, the `qty_available` at date will be incremented
- in the same usecase, the remaining_qty and remaining_value is
  incremented in place, which mean that even if the layer was already
  consumed, it's now appearing again at the bottom of the fifo layer

Fixing this issue by adding a stock move at the date of today instead of
editing in place in v11 and adding a proper "cost layer" model in master
was deemed too complex as well as unnecessary by our bosses

So we now say we continue to update in place, and when looking at the
quantity at date
- if periodic, we sum the value of the move since the beginning of times
- if perpetual, we sum the balance of the account move lines since the
  beginning of times. Also, in this case, the quantity at date is
  computed across account move lines too, via the "quantity" field on
  aml.

This commit adds three non stored computed field:
- qty_at_date: will be computed across stock moves if fifo periodic and
  across account move line if fifo perpetual to reflect the design
  choice: if periodic, we *really* edit in the past ; if perpetual, no,
  the change is done at today's date
- stock_fifo_real_time_aml_ids: the used aml to compute qty_at_date
- stock_fifo_manual_move_ids: the used move to compute qty_at_date

stock value should be recomputed when the standard price change

it is not optimal since it is updated in fifo after a delivery but
needed when working with standard cost method

remaining_value should also be part of the depends since the current
value depends on it

Properly set the quantity field on the account move lines when
exceptions happen (unlock and edit: only the difference is set as
quantity, negative stock and vacuum: no quantity should be set).

When applying a landed cost, no quantty should be set neither.

This is a preliminary work to bring the valuation at date wizard to v11.

Update the value on the moves when exceptions happen (unlock and edit,
negative stock).

This is a preliminary work to bring the valuation at date wizard to v11.

We also update the value on moves in the standard cost method to stay
consistent.

- `_run_fifo` now returns the used value in the negative stock case
- we simplify the `_fifo_vacuum` method so that the `remaining_value`
  always represent the not yet compensated value
- we adapt the tests to reflect theses changes ; the value is not the
  initial valued amount but is updated upon exceptions

Since April 1, 2018, free versions of GeoLite Legac y databases are no
longer updated and free downloads not available [1].

[1] https://support.maxmind.com/geolite-legacy-discontinuation-notice/

Make sure the variable is casted to an integer when getting taxes.

opw-1830862

Replace `httprequest.stream.read()` by `httprequest.get_data()` so the
payload content remains available: get_data stores the request body (by
default) so it remains available for alternative processing or checks
(MAC checks for webhook validations for instance). With `stream.read()`,
once the data is read if it's not stored separately it is lost.

Have a task (A) with two subtasks (B and C)
Archive C

Before this commit, when using timesheets, the task A hours was misconputed and did not take C's timesheet into account

After this commit, hours are accounted for even if their task is archived

OPW 1829658
closes #23920

Issue: when displaying the shortcuts with ALT key, when a dialog is open
the shortcuts are displayed in absolute position above the gray overlay
of the dialog, so it is possible to click on the buttons of the
shortcuts.
This fix will remove this possibility.

Reproduce the issue:
- open the manual reconciliation (it is a client action)
- add a reconciliation (using the + sign)
- expand it (using the > sign)
- put the focus on the first field and hit TAB
--> you would expect that the focus moves to the second field
--> what happens is: the focus stays on the first field

Before this fix, when in a client action (or any place that contains
fields) that contains fields, the keyboard navigation did not occur
correctly because the default behavior of the TAB key was prevented.

After this fix, if the navigation_move event was not stopped, we allow
the default behavior of the TAB key.

If a user set a procurement to the day N, the procurement datetime field would
be set to day N at midnight. So any negative timezone make it appear that the
procurement is set to day N-1.

opw 1831272

Before this rev., the datepicker could only be opened by clicking
on the input, not on its caret.

OPW 1836520

Since July 1, 2007, the Sudanese pound is the only legal tender.

Closes #13802

d28f8f70 carefully clears only the
relevant bit of the cache (only the top-level object which we're
exporting), however the commit did not considert that _export_rows
calls itself recursively for relational fields, and thus when
exporting relational fields the relation would become the new
top-level and get cache-cleared on every iteration, significantly
slowing down cases where such records are shared and would need to be
re-fetched every iteration, even more so if they're somewhat/somehow
expensive.

OPW-1833545
OPW-1836361

While c059e7b93c64b9dd9bc96eeb6ee5cadf significantly lowers the cost
of generating xids, a safety invalidate cache can regress cases
significantly e.g. 18s -> 430s (7mn) for some recursive exports of
xids as the cache would be completely cleared *after each record*
requiring complete fetching & recomputation of the following records.

Fix by only clearing the cache if we've actually had to create
xids *and* only for ir.model.data records.

It's possible that clearing the cache isn't even necessary at all (?),
check with @rco-odoo

OPW-1835226