Currently, an exception is raised while loading icon content assets
such as `.woff` or `.woff2`, due to a mismatch between the requested
asset version and the latest available version.

Steps to produce:
- Install website
- Open page `/web/assets/1/6a783c3/web.odoo_ui_icons.min.woff2`

Error: `UnboundLocalError: cannot access local variable 'assets' where it is not associated with a value`

This issue occurs because the code at [1] compares `binary.extension` with
`asset_type`, causing the condition to fail because `binary.extension` contains
values such as `woff` or `woff2`, while `asset_type` is set to `'binary'`.

The root cause is that `asset_type` with value `'binary'` is being passed as
a parameter to the `bundle.get_link` method (see [2]). The `asset_type`
value comes from the `_parse_bundle_name` method (see [3]), where it is
set to `'binary'` whenever the file extension belongs to `BINARY_EXTENSIONS`,
such as `woff` or `woff2` (see [4]).

This commit fixes the inconsistency between `bundle.get_version()`
and `bundle.get_link()` when `binary` is `True`.

Currently, `bundle.get_version()` used `extension if binary else asset_type`,
while `bundle.get_link()` always received `asset_type`. This could lead to an
incorrect redirect when handling binary assets.

The fix normalizes the value by updating `asset_type` beforehand and reusing
it consistently in both `bundle.get_version()` and `bundle.get_link()`. This
also improves readability by removing the inline conditional expression.

[1]: https://github.com/odoo/odoo/blob/8a2e001cffd381a89ab192f2e391ccc0843108c4/odoo/addons/base/models/assetsbundle.py#L166
[2]: https://github.com/odoo/odoo/blob/8a2e001cffd381a89ab192f2e391ccc0843108c4/addons/web/controllers/binary.py#L146
[3]: https://github.com/odoo/odoo/blob/8a2e001cffd381a89ab192f2e391ccc0843108c4/odoo/addons/base/models/ir_asset.py#L93-L94
[4]: https://github.com/odoo/odoo/blob/8a2e001cffd381a89ab192f2e391ccc0843108c4/odoo/tools/constants.py#L6-L7

Sentry-7441025709

Forward-Port-Of: odoo/odoo#263506

Creating a bank account with a falsy proxy value generates a traceback.

Steps to reproduce the error:
- Install ``l10n_br`` module with demo data
- Switch to BR Company
- Go to Contacts > Configuration > Bank Accounts > Create a new bank account >
  Add any value as Account Number >  Account Holder: BR Company >
  Proxy Type: CPF/CNPJ(BR) or Random Key (BR) > Save

Traceback:
```py
InvalidFormat: The number has an invalid format.
```
```py
TypeError: 'bool' object is not iterable
```

https://github.com/odoo/odoo/blob/132f042ca14012877f608783b57a0ca9c4e565f3/addons/l10n_br/models/res_partner_bank.py#L38-L45
For ``CPF/CNPJ`` validation, calling ``check_vat_br`` with a falsy proxy value
raises a traceback.

https://github.com/odoo/odoo/blob/132f042ca14012877f608783b57a0ca9c4e565f3/addons/l10n_br/models/res_partner_bank.py#L56-L61
For ``Random Key`` validation, ``re.fullmatch`` expects a string value,
but receives ``False``, leading to a traceback.

sentry-7488238698

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#266243
Forward-Port-Of: odoo/odoo#264995

Currently, an error occurs when the user checks the report line errors.

**Steps to Reproduce:**

 - Install the `l10n_hk_hr_payroll_empf` module with demo data.
 - Switch to the `Hong Kong` company.
 - Go to `Payroll` > `Reporting` > `Hong Kong` > `eMPF Contributions`.
 - Create a record by setting the `Scheme` and adding a `contribution line`.
 - Ensure that the employee and payslip fields are empty in the contribution line.
 - Click on `Validate`, then click on the `error icon` on the report line.

`ValueError: Expected singleton: hr.version()`

This error occurs when the user manually adds a line and checks the errors on it.. The system 
attempts to open the employee record from the version [1], but the version is not set [2] on the 
line because there is no employee. And it raise the error [3].

This commit ensures that when checking errors, if the version is not set on the line, a UserError 
is raised, prompting the user to set the employee on the line. It also corrects a typo in the status 
message.

[1]- https://github.com/odoo/enterprise/blob/7889b2b0b3d13b32e6e36e616e20379d8c8f8812/l10n_hk_hr_payroll_empf/model/l10n_hk_empf_contribution_report_line.py#L219

[2]- https://github.com/odoo/enterprise/blob/7889b2b0b3d13b32e6e36e616e20379d8c8f8812/l10n_hk_hr_payroll_empf/model/l10n_hk_empf_contribution_report_line.py#L142-L156

[3]: https://github.com/odoo/odoo/blob/98855c6b70df24500babe6027109aa9e17431ec1/addons/hr/models/hr_version.py#L609-L611

Forward-Port-Of: odoo/enterprise#116607

### Description

`account.full.reconcile` has no `unlink()` override, so when the record is removed PostgreSQL nulls `full_reconcile_id` on the linked `account.move.line` rows via the default `ondelete='set null'` FK rule, but `matching_number` is a plain `fields.Char` that nobody recomputes. The line ends up with a decimal `matching_number` (the id of the deleted full) while `full_reconcile_id` is `False`, no partials point to it and `amount_residual` is the full open amount. The line is rendered as reconciled in the UI even though the reconciliation is gone.

This PR mirrors `account.full.reconcile.create()`'s contract on the unlink path: invoke `_update_matching_number(amls)` after the records are removed, so every previously-linked line is cleaned. The integrity check `_constrains_matching_number` is also extended with `full_reconcile_id` in its `@api.constrains` tuple, so future ORM writes that desync the field surface the inconsistency immediately.

### Steps to reproduce

A single-call reproducer on a vanilla `19.0-all` runbot, no third-party modules:

```python
company = env.ref('base.main_company')                       # USD company
partner = env['res.partner'].create({'name': 'demo'})

# Foreign currency rates with a sharp move so the payment generates an FX diff
env['res.currency.rate'].create([
    {'currency_id': env.ref('base.EUR').id, 'name': '2026-01-15', 'rate': 0.90, 'company_id': company.id},
    {'currency_id': env.ref('base.EUR').id, 'name': '2026-03-15', 'rate': 1.20, 'company_id': company.id},
])

inv = env['account.move'].create({
    'move_type': 'out_invoice', 'partner_id': partner.id,
    'currency_id': env.ref('base.EUR').id,
    'invoice_date': '2026-01-15', 'date': '2026-01-15',
    'journal_id': env['account.journal'].search([('type','=','sale')], limit=1).id,
    'invoice_line_ids': [(0,0,{'name':'x','quantity':1,'price_unit':1000.0})],
})
inv.action_post()

env['account.payment.register'].with_context(
    active_model='account.move', active_ids=inv.ids
).create({'payment_date': '2026-03-15'}).action_create_payments()

recv = inv.line_ids.filtered(lambda l: l.display_type == 'payment_term')
full = recv.full_reconcile_id
assert full and recv.matching_number == str(full.id)

full.unlink()                                                # the bug detonator
recv.invalidate_recordset()
assert recv.matching_number is False                         # FAILS without this PR
assert not recv.full_reconcile_id
```

Before the PR `recv.matching_number` keeps the decimal id of the deleted `account.full.reconcile`. After the PR it is cleared together with `full_reconcile_id`.

### Diagnostic query

```python
env['account.move.line'].search([
    ('matching_number', '!=', False),
    ('matching_number', 'not like', 'P%'),
    ('matching_number', 'not like', 'I%'),
    ('full_reconcile_id', '=', False),
])
```

Returns lines in the orphan state on any database.

### Impact

Observed on a real production database: 142 `account.move.line` records in this orphan state accumulated over ~13 days of normal accounting activity, on receivable, payable and bank accounts. All those lines display as reconciled in the UI while the underlying reconciliation is gone. Empty `account.full.reconcile` rows are also left behind.

### Tests

`addons/account/tests/test_account_move_reconcile.py::TestAccountMoveReconcile::test_full_reconcile_unlink_clears_matching_number`

### Linked

* Bug report: closes #264790

The change is a single-file 13-line `unlink()` override plus a one-character extension to an existing `@api.constrains` tuple. No data migration is needed for new databases; existing orphans on databases that hit the bug before the fix lands can be cleaned with a one-off:

```python
env['account.move.line'].search([
    ('matching_number', '!=', False),
    ('matching_number', 'not like', 'P%'),
    ('matching_number', 'not like', 'I%'),
    ('full_reconcile_id', '=', False),
]).write({'matching_number': False})

env['account.full.reconcile'].search([
    ('reconciled_line_ids', '=', False),
    ('partial_reconcile_ids', '=', False),
]).unlink()
```

Forward-Port-Of: odoo/odoo#264805

The total of a sale order containing a combo product that has an extra price is not correclty converted to the sale order's pricelist currency

Steps to reproduce:
1. Install Sales
2. Go to Invoicing > Configuration > Accounting > Currencies and activate currency MXN
3. Go to Sales > Products > Pricelists and create a new pricelist for currency MXN
4. Go to Sales > Products and create a new combo product "test"
5. Create a combo choice "combo" with options "Large Cabinet" and extra price 10000$
6. Go to Sales and create a new quotation for customer Acme Corporation with product "test" (total is $10,001)
7. Change the pricelist to MXN and update prices
8. The total is ~MX$10,018 (it should be ~MX$186,682)

Issue:
The extra price of a combo product is not converted to the sale order's pricelist currency, so we end up adding the price of the product in the order's currency with the extra price not converted

Solution:
Convert the extra price of the combo product to the sale order's pricelist currency

opw-6192935

Forward-Port-Of: odoo/odoo#266172
Forward-Port-Of: odoo/odoo#265008

Previously, the file containing the Knowledge print assets was lazy-loaded when the user triggered a print action through the UI. However, printing can also be initiated through other mechanisms (keyboard shortcuts, contextual menu, etc.), which prevented us from consistently detecting when to load the assets. In those cases, the assets were not loaded and the article appeared blank (see: odoo/enterprise#70243).

To ensure the assets are always loaded regardless of how printing is triggered, we moved them to the common print bundle and adopted the standard asset-loading approach. This change also simplifies the codebase by removing JavaScript workarounds previously used to load the assets dynamically.

However, some CSS rules in the Knowledge print stylesheet target global elements such as the web client container. Since the stylesheet is now included in a global asset bundle and always loaded, these rules apply to all modules and may cause rendering issues when printing views outside of Knowledge.

To prevent such side effects, the CSS rules in `knowledge_print.scss` will be updated to use more specific selectors. The rules will be scoped so they only apply when the container includes the Knowledge view (using the `:has`).

This PR also refactors the stylesheet by removing outdated rules that no longer match any elements. Several of these rules predate the major UI refactoring introduced in Odoo 16.

Task-5999878

Forward-Port-Of: odoo/enterprise#109379

## Issue
In the Recruitment app, users with the *Interviewer* role have access to the Talent Pool action menu, can see the different talent pools, but don't have any read/write access to the applicants within the pools, and cannot create new pools either.

## Steps to reproduce
1. Install *Recruitment* (`hr_recruitment`) with demo data
2. Set Marc Demo's *Recruitment* role to *Interviewer*
3. As Marc Demo, navigate to Recruitment > Applications > By Talent Pools
4. **We can see the existing pools, but they all appear empty ("0 Talents"), and we cannot add talents to a pool, nor create new pools.**

## Cause
Interviewer do not see any applicants in the talent pools because of the following rule:

https://github.com/odoo/odoo/blob/e751fa1e010dbda63903d598048ef415709b4af4/addons/hr_recruitment/security/hr_recruitment_security.xml#L48-L60

In fact, applicants in talent pools do not have a job_id set:

```sql
190=# SELECT a.partner_name, a.job_id FROM hr_applicant a
190-# JOIN hr_applicant_hr_talent_pool_rel tpr
190-# ON (tpr.hr_applicant_id=a.id);

 partner_name  | job_id
---------------+--------
 Cameron Ellis |
 Ethan Carter  |
 Noah Bennett  |
 Test Talent   |
(4 rows)
```

This leads to no applicants being shown to the interviewers in the talent pools.

## Justification
Interviewers by default only have access to applications who they are interviewer for, it is not intended for them to see entire pools of potential candidates. Letting interviewers access the talent pools view is counter-intuitive, as they have nothing they can do from there.

opw-6187187

Forward-Port-Of: odoo/odoo#265812

still ``lxml.html.clean`` import is needed because ``lxml.html``  init file don't have clean file. So, it
will be not loaded
For reference :-  https://github.com/lxml/lxml/blob/lxml-4.9/src/lxml/html/__init__.py
```
Traceback (most recent call last):
  File "/tmp/tmpj23nirpw/odoo/19.0/./odoo-bin", line 3, in <module>
    import odoo.cli
  File "/tmp/tmpj23nirpw/odoo/19.0/odoo/cli/__init__.py", line 2, in <module>
    from .command import Command, main  # noqa: F401
  File "/tmp/tmpj23nirpw/odoo/19.0/odoo/cli/command.py", line 8, in <module>
    import odoo.init  # import first for core setup
  File "/tmp/tmpj23nirpw/odoo/19.0/odoo/init.py", line 28, in <module>
    from .tools.gc import gc_set_timing
  File "/tmp/tmpj23nirpw/odoo/19.0/odoo/tools/__init__.py", line 11, in <module>
    from .i18n import format_list, py_to_js_locale
  File "/tmp/tmpj23nirpw/odoo/19.0/odoo/tools/i18n.py", line 8, in <module>
    from odoo.tools.misc import babel_locale_parse, get_lang
  File "/tmp/tmpj23nirpw/odoo/19.0/odoo/tools/misc.py", line 40, in <module>
    from lxml import etree, objectify
  File "<frozen importlib._bootstrap>", line 1027, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1006, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 688, in _load_unlocked
  File "/tmp/tmpj23nirpw/odoo/19.0/odoo/_monkeypatches/__init__.py", line 45, in exec_module
    patch_module(module.__name__)
  File "/tmp/tmpj23nirpw/odoo/19.0/odoo/_monkeypatches/__init__.py", line 67, in patch_module
    module.patch_module()
  File "/tmp/tmpj23nirpw/odoo/19.0/odoo/_monkeypatches/lxml.py", line 14, in patch_module
    lxml.html.clean._find_image_dataurls = re.compile(r'data:image/(.+?);base64,').findall
AttributeError: module 'lxml.html' has no attribute 'clean'
```
https://upgradeci.odoo.com/upgradeci/run/301804


---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#266591

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/96730cde0f [REL] 19.2.14 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/28ee06827e [FIX] formulas: add IFERROR second argument when exporting data [Task: 5993405](https://www.odoo.com/odoo/2328/tasks/5993405)
https://github.com/odoo/o-spreadsheet/commit/678ec266bb [FIX] range: correctly handle unbounded ranges on row/col changes [Task: 6167358](https://www.odoo.com/odoo/2328/tasks/6167358)
https://github.com/odoo/o-spreadsheet/commit/1c0c884d4c [FIX] pivot: unused pivot detection with composed formula [Task: 6105894](https://www.odoo.com/odoo/2328/tasks/6105894)
https://github.com/odoo/o-spreadsheet/commit/ae67cd345d [FIX] pivot: unused pivot detection with calculated measure [Task: 6105894](https://www.odoo.com/odoo/2328/tasks/6105894)
https://github.com/odoo/o-spreadsheet/commit/6b043bb023 [IMP] claude: add review skill [Task: 6223095](https://www.odoo.com/odoo/2328/tasks/6223095)
https://github.com/odoo/o-spreadsheet/commit/67d2c05b68 [IMP] claude: add testing skill [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/1c38e43a90 [IMP] claude: add CLAUDE.md file [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)

Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>

# How to reproduce
- Install the Events, Porject & CRM apps
- Create two event A & B with tickets that can be purchased
- Go to Events > Configuration > Lead Generation
- Create a Lead Generation Rule with :
	- Create : Per Order
	- When : Attendees are created
	- Event : None
- Create a new quotation with two lines :
	- Product : Even Registration for event A 1st, then B
- Confirm the SO

# The problem
A traceback will appear

# Cause of the issue
When confirming the SO, we create `event.registrations`s that will check for
lead generation rules and create or update `crm.lead`s accordingly :
https://github.com/odoo/odoo/blob/3bf89b4f467390807c20f7b007a875a77542e76f/addons/event_crm/models/event_registration.py#L35

We will then group the registrations by leads & grouping model :
https://github.com/odoo/odoo/blob/3bf89b4f467390807c20f7b007a875a77542e76f/addons/event_crm/models/event_lead_rule.py#L166

For all groups, if the lead does not exist, we create one :
https://github.com/odoo/odoo/blob/3bf89b4f467390807c20f7b007a875a77542e76f/addons/event_crm/models/event_lead_rule.py#L184-L187

`_get_lead_values()` works fine with multiple `event.registrations`s, but crashes
when those registrations does not have all the same event, which is our case :
https://github.com/odoo/odoo/blob/3bf89b4f467390807c20f7b007a875a77542e76f/addons/event_crm/models/event_registration.py#L170

# Proposed solution
Since we have multiple events and leads are associated to a single event :
https://github.com/odoo/odoo/blob/3bf89b4f467390807c20f7b007a875a77542e76f/addons/event_crm/models/crm_lead.py#L11

We group the registrations by event and create multiple leads accordingly

opw-6167518

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#265017

Before this commit, for DBs with a very large number of products it was possible for the thread to run out of memory when importing an invoice or a bill.
The reason is that the name on product.product is non stored and computed. This leads to tons of recomputes, which in turn leads to reads and stores in cache of the underlying `product.product`, which down the line uses up all of the available memory for the thread.

The proposed method uses batches instead of a `search_fetch` as the latter would not solve the recompute problem and hence the underlying memory problem.
Another alternative approach could be going straight for the `product.template.name`, but that approach might introduce a loss of precision or functionality when searching for products at invoice import.

Here is the memory graph from memray before the fix:
<img width="1106" height="450" alt="opw-6168737-memray-pre-fix" src="https://github.com/user-attachments/assets/f971dc4d-aa09-41e3-a8c5-e5ca53f9786d" />

And here is the same graph after the fix:
<img width="1106" height="450" alt="opw-6168737-memray-post-fix" src="https://github.com/user-attachments/assets/0a784cdc-9b40-498b-bbcb-89114eec1ec9" />

We can see a much lower peak memory usage after the fix. We an also observe that the memory complexity shifts from `O(n)` to `O(1)`, with `n` being the number of `product.product` records stored in the DB.

For both presented graphs, the same, unaltered database was tested. The database contains 389 467 `product.product` records.

opw-6168737

Forward-Port-Of: odoo/odoo#265639
Forward-Port-Of: odoo/odoo#262591

***Steps to reproduce*:**

- Create and confirm an invoice.
- Open the invoice preview and use the Print option to generate the PDF.
- Send the invoice to the customer.

***Observed behavior*:**

- In the preview, the header is displayed as *Proforma*.
- Before sending the invoice, the downloaded PDF from the Print option does not contain the *Proforma* header.
- After sending the invoice, the preview correctly no longer shows the *Proforma* header, but the Print PDF output also continues without the expected behavior.

***Cause*:**

- The *Proforma* header should be displayed when a confirmed invoice has not yet been sent to the customer.
- Once the invoice is sent, the document should display the normal invoice header instead.
- The PDF generation flow from `action_print_pdf` did not correctly pass the proforma context based on whether the invoice had already been sent.

***Fix*:**

- Update the functional logic in `action_print_pdf` to use: `with_context(proforma_invoice=not self.invoice_pdf_report_id)`
- This ensures that invoices not yet sent to the customer are generated as *Proforma* invoices.
- Once the invoice has been sent, the PDF is generated with the normal invoice header instead.

opw-6169132

Forward-Port-Of: odoo/odoo#265825

**Steps to reproduce**
- Have user A with Sign admin rights and user B without Sign rights.
- With user A, create a sign request activity on a record that user B can access. Send the signature request.
- With user B, try to access the record. -> AccessError when trying to fetch the chatter.

**Cause**
By default, users get access to all the activities associated to records they have access to (see `_search` of `mail.activity`). This is an issue since some of the fields added in `_store_activity_fields` for the sign request activity display might not be accessible for a user with access to the activity.

**Change**
Use `sudo` to be able to display the activity, even if the user doesn't have access to the sign request.
Also, in that case, `can_write` should be `False` in order to hide the action buttons of the activity, which trigger access errors when trying to make operations on the sign request.

Another related change is to create the activity for the user creating the sign request, this avoids falling back on the `user_id` of the record associated with the activity and makes sure the activity's user has access to the sign request.

opw-6157455

**PROBLEM**
In some case, because of rounding issues, the withholding base amount can be bigger than the total amount of the invoice, which should not be the case.

**STEP TO REPRODUCE**

1. Install l10n_pe_edi
2. Create an invoice with those 2 lines: qty: 300, unit_price: 0.481936, tax: VAT 18% + 3% IGV Withholding qty: 300, unit_price: 0.747376, tax: VAT 18% + 3% IGV Withholding
3. Confirm the invoice, and send the xml (if this fail, you may have to change the name of the invoice, using odoo inspector or other means).
4. Open the xml, and notice the base amount for the allowance on the document level is 435.18 which is bigger than the invoice payable amount.

**CAUSE**
We exclude the withholding taxes to compute the invoice taxInclusiveAmount. When computing this amount, we round the line base and the tax total of the VAT 18% tax leading to the result of 435.17. When creating the allowance node for the Withholding taxes, the base used for the withholding taxes is the sum of the line base, and the tax total of previous tax NOT rounded. There is no easy way to change the withholding tax computation, so we just limit the base to not be bigger than the invoice total when there is rounding issues.

opw-6010388

Forward-Port-Of: odoo/enterprise#113689

### Steps to reproduce:

- In the settings enable: Multi-steps routes
- Inventory > Configuration > Warehouse Management > Routes
- Unarchive MTO
- Create a storable product P with a bom using the MTO Route
- In the Miscellaneous tab of the bom tick Batch Size and set it to 2
- Create and confirm a sale order for 6 units of P
#### > Three MO's are created but only the last one will update the quantities of the delivery at validation of the production.

### Cause of the issue:

The `move_dest_ids` of the `move_finished_ids` is only set on the last of the three productions. That is only the last MO is properly chained to the delivery via an MTO chain. This happens because the `move_dest_ids` field of the `mrp.production` model is a `One2Many` field: https://github.com/odoo/odoo/blob/a2f072fe99a03aaf521bba1965e7f29a1c99e325/addons/mrp/models/mrp_production.py#L223-L224 Which implies that each move can be linked to at most one mrp.production via the `created_production_id` field. However, if you have set a batch size on your bom, it is expected for a single move to create multiple mo's. While the `move_dest_ids` of each of these MO is appropriately set in the create vals to be the mto `stock.move` of the delivery, due to the nature of the `created_production_id` field only the *last* mo will created with a set `move_dest_ids` as this is the only record that will be set as `created_production_id`. However, after the creation of these MO's, the related `move_finished_ids` will be recomputed:
https://github.com/odoo/odoo/blob/a2f072fe99a03aaf521bba1965e7f29a1c99e325/addons/mrp/models/mrp_production.py#L1089-L1093 However, the `move_dest_ids` of the created moves will be set to be either the `move_dest_ids` of their production (which is unset for all but the last one) or these of the first production of the same `production_group` that is these generated by a common production split: https://github.com/odoo/odoo/blob/a2f072fe99a03aaf521bba1965e7f29a1c99e325/addons/mrp/models/mrp_production.py#L1263-L1267
Now, since neither are set in our use case, the `move_dest_ids` will not be set on the `move_finished_ids` which implies in particular that the mto link between our productions (but the last one) and the delivery is lost.

Fix:

Since we can not change the nature of the `move_dest_ids` and `created_production_id` in stable to become Many2Many fields, we need to find a way to propagate the `move_dest_ids` on moves without relying on the probably inaccurate value provided by the production. And, since the compute of the `move_finished_ids` could be launched at many other points than during a create process (because of the many dependencies), we can not solely rely on the creation context but rather new to provide a way to recreate the link from relations at any given point. We therefore rely on the `stock.reference`'s similar to what was done prior to 19.0 via the `procurement_group_ids`: https://github.com/odoo/odoo/blob/132f042ca14012877f608783b57a0ca9c4e565f3/addons/mrp/models/mrp_production.py#L1198-L1202

opw-6188069

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#264951

**Problem**:
When we set the quantity of a move to zero, then add serial numbers manually, if the serial numbers are not the first ones in the list of available serial numbers, The first few available serial numbers will be added to the move, which causes a mismatch of quantity and the number of serial numbers.

**Before this commit:**
If we have three serial number SN-001, SN-002, SN-003 created in order, and we set the quantity of the move to zero, then add SN-002 and SN-003 manually, SN-001 will be added automatically while saving.

**After this commit:**
Only SN-002 and SN-003 will be added to the move, which matches the quantity.

**Steps to reproduce:**
1. Create a product with tracking by unique serial number, and create 3 lots SN-001, SN-002, SN-003 for this product.
2. Create a picking and add a move for this product, set the demand to 3 and quantity to 0.
3. Set the quantity to 2, and add SN-002 and SN-003 to the move, then save the picking.
4. SN-001 will be added to the move automatically, but the quantity stays at 2.

opw-6121208

Forward-Port-Of: odoo/odoo#266259
Forward-Port-Of: odoo/odoo#263080

When we create a product variant and have a pricelist 
which is based on the cost price, and change the cost price, 
the on_sale_price doesn't update. You have the change the price 
list to other and back to the one you want for it to trigger 
change because the _onchange_compute_pricing only gets 
triggered if there's change on pricelist (pricer_sale_pricelist_id), 
and sales price (lst_price).

Steps to Reproduce:
1.Create a pricelist and add a line with "formula" price type, 
and based on "cost",
2.Create a product variant, and add the pricelist
just created.
3.Change the "Cost". The "On Sale Price" doesn't update. 
4.You have to change the price list to some other
and back to the one you want for the "On Sale Price" to update.

To fix the issue, we add the field Cost (standard_price) on 
api.onchange, so when we change the cost it'll
update the "On Sale Price" right away.

opw-5947995

Forward-Port-Of: odoo/enterprise#117806
Forward-Port-Of: odoo/enterprise#111892