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 is produced when sending invoices to MyInvois if the invoice number uses a year-range sequence.

**Steps to Reproduce:(v-19.0)**
1. Install the `accountant` and `l10n_my_edi` modules (with demo data).
2. Switch to "MY Company"(Malaysian company).
3. Enable "_Quick Encoding_" for Customer Invoices in Settings.
4. Create a customer invoice with customer "_MY Company_", set a Malaysian classification code and taxes on the invoice line, and confirm the invoice.
5. Set the invoice back to Draft and modify the invoice number with a year-range sequence (e.g., INV/2025-2026/00001), then confirm it again.
6. Open the invoice list view and click **"Send to MyInvois"**.

**Error:**
`ValueError: not enough values to unpack (expected 4, got 2)`

The `_get_sequence_date_range()` method on `myinvois.document` overrides the method from `sequence.mixin` and returns only two values from `date_utils.get_fiscal_year()`. However, it expects the method to return four values at [1].

[1] - https://github.com/odoo/odoo/blob/57b6b8d63b038ede32dfcc833c30e93d0cf4166c/addons/account/models/sequence_mixin.py#L146
Ref: https://github.com/odoo/odoo/blob/1ce06257f877711bd5de5487364909d72b476318/addons/account/models/account_move.py#L4263

sentry-7320998540

Forward-Port-Of: odoo/odoo#266221
Forward-Port-Of: odoo/odoo#253237

### 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

***=im_livechat**

**Steps to Reproduce: [Livechat case]**
- Start a Live Chat conversation between an Operator and a Visitor.
- From the operator side, click Reply on a visitor message.
- From the visitor side, close the conversation.
- Return to the operator side.
- Observe that the replyToMessage composer is still visible even though 
the live chat has ended.

**[Channel Read-only case]**
- Create a channel between two users.
- Ensure the channel is writable initially.
- From one user's side, click Reply on another user's message.
- While the user is in reply mode, make the channel read-only from the admin side.
- Return to the replying user's side.
- Observe that the reply-to-message composer is still visible even though 
the channel has become read-only.

**Current behavior before PR:**
Before this PR, the reply composer could remain visible after the 
conversation became unavailable for replying, such as when a channel 
turned read-only again or when a livechat conversation ended.

**Desired behavior after PR is merged:**
After this PR, the reply composer is automatically dismissed whenever 
replying is no longer possible, keeping the composer state consistent 
with the conversation state.

task-[6208973](https://www.odoo.com/odoo/project/1519/tasks/6208973)

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

Forward-Port-Of: odoo/odoo#265487

## 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

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

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

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

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

This commit resolves multiple issues in the Vietnamese accounting reports module:

1. Appendix 142 PDF Export Crash:
   - Extracted the PDF sectioning logic into a new `_get_pdf_sections` method.
   - Added safeguards to gracefully handle cases where the report has no lines, preventing an `IndexError` when attempting to access `lines[-1]`.
   - Added unit tests to ensure empty lines are correctly parsed without crashing.

2. XML Data and Dependency Fixes:
   - Fixed an invalid `report_id` reference in `account_return_data.xml` by correctly pointing it to `l10n_vn_reports.l10n_vn_tax_report` instead of `l10n_vn.form_01_gtgt_report`.
   - Reordered the `__manifest__.py` data loading sequence. `account_tax_report_data.xml` now loads before `account_return_data.xml` to prevent "External ID not found" errors during module installation/upgrades.

3. Naming and Sequencing Improvements:
   - Renamed "Vietnamese Tax Report" to "VAT Declaration - 01/GTGT" to reflect the actual Vietnamese tax form accurately.
   - Added explicit `sequence` fields to the tax reports (VAT Declaration: 10, Appendix 142: 20) to ensure proper UI ordering.

Task-6216318

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/0cf1540a3f [REL] 19.3.5 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/079996753d [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/46d7a7645a [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/a8deb38b10 [FIX] Chart type: keep the label range when changing the chart type [Task: 6197123](https://www.odoo.com/odoo/2328/tasks/6197123)
https://github.com/odoo/o-spreadsheet/commit/6fc6a5f456 [FIX] Chart type: first chart type change resulted in empty chart [Task: 6197123](https://www.odoo.com/odoo/2328/tasks/6197123)
https://github.com/odoo/o-spreadsheet/commit/07397934ad [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/b157f2c97c [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/6010f72a6c [IMP] claude: add review skill [Task: 6223095](https://www.odoo.com/odoo/2328/tasks/6223095)
https://github.com/odoo/o-spreadsheet/commit/99418f299d [IMP] claude: add testing skill [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/4df8cb15be [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>