**Steps to reproduce**
- Open any MO
- Click on 'catalog'
- Click on the three dots button of any product
- Try to edit
-> Traceback: `"product.product"."state" field is undefined.`

**Cause**
The `move_raw_ids` field on the MO form sets a context with `form_view_ref: 'mrp.view_mrp_stock_move_operations'`, so that editing a component's `stock.move` line in place opens that dedicated view: https://github.com/odoo/odoo/blob/20db2910d16fa6ebd07794fb9ed3fb1c8f57b0fc/addons/mrp/views/mrp_production_views.xml#L411-L417 The 'Catalog' button lives inside that same field, and calls `action_add_from_catalog_raw`, which delegates to the mixin's `action_add_from_catalog`: https://github.com/odoo/odoo/blob/3dd41395e2e4205fa477eb474d4a4dba0a976154/addons/product/models/product_catalog_mixin.py#L17 Which conserve the `'form_view_ref'` from context: https://github.com/odoo/odoo/blob/3dd41395e2e4205fa477eb474d4a4dba0a976154/addons/product/models/product_catalog_mixin.py#L28 and that action requests its form view with `view_id=False`: https://github.com/odoo/odoo/blob/3dd41395e2e4205fa477eb474d4a4dba0a976154/addons/product/models/product_catalog_mixin.py#L25 Which will try to load `view_mrp_stock_move_operations`, since: https://github.com/odoo/odoo/blob/3dd41395e2e4205fa477eb474d4a4dba0a976154/odoo/addons/base/models/ir_ui_view.py#L3002-L3005 `_get_view` never checks that the resolved view's `model` matches the model it was asked for, so it returns `view_mrp_stock_move_operations`for the `product.product` model: https://github.com/odoo/odoo/blob/3dd41395e2e4205fa477eb474d4a4dba0a976154/addons/mrp/views/stock_move_views.xml#L41 https://github.com/odoo/odoo/blob/3dd41395e2e4205fa477eb474d4a4dba0a976154/addons/stock/views/stock_move_views.xml#L128 `state` doesn't exist on `product.product`, hence the crash.

opw-6433620

Forward-Port-Of: odoo/odoo#279811

Prior to this commit, the call debrief timeline was not properly adapted for RTL layouts. The playhead and timestamp were positioned incorrectly, making the component unusable in RTL.
This commit forces the timeline to always render in LTR, as it represents the physical progression of time moving forward.

task-6445011

Requires:
- https://github.com/odoo/enterprise/pull/127038

| Before | After |
|--------|--------|
| <img width="1920" height="698" alt="image" src="https://github.com/user-attachments/assets/780f6e83-b67d-44bc-8b00-8e92048ff13b" /> | <img width="1390" height="463" alt="Screenshot 2026-08-11 at 08 51 00" src="https://github.com/user-attachments/assets/8a2a833c-2164-40ed-a4c7-006b7ca5bec4" /> |
| <img width="1385" height="418" alt="Screenshot 2026-08-04 at 15 02 05" src="https://github.com/user-attachments/assets/f0c75f29-e459-4ee7-976d-3674ae76ff81" /> | <img width="1384" height="479" alt="Screenshot 2026-08-11 at 08 51 22" src="https://github.com/user-attachments/assets/f60b98c5-5a33-4d01-8521-0f2f3bdd6424" /> |



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

Currently, with images enabled for quotation reports and if the product name is long enough, it overflows through the column border a bit before breaking to the next line.

This seems to be caused by some incompatibility between wkhtmltopdf and d-flex, adding `col` to the product name container forces it to respect column boundaries.

This commit also adds `text-break` as having a long uninterupded string in the description would end up stretching the column and making the next ones disapear.

<img width="811" height="266" alt="image" src="https://github.com/user-attachments/assets/90043c88-d03f-4324-9935-e669f6a256ab" />

<img width="964" height="431" alt="image" src="https://github.com/user-attachments/assets/2b8e8a6c-6fd5-4813-8160-d94bbb5490d1" />


### Steps to reproduce:
- Enable Display Product Images in the setting
- Create a product with an image
- Create a quotation with said product and add a description that is long enough to break to the next line
- Print said quotation
- You will notice that before the line breaks it will overflow to the next column 
(you might need to tweak the description a bit by removing or adding a few lines)


opw-6367076

Forward-Port-Of: odoo/odoo#275978

Clicking the internal-link arrow on `work_entry_type_id` (Time Off Type) implicitly saved the `hr.leave` record before opening the related form dialog, since `Many2One.openRecordInDialog()` calls `willOpenRecordInDialog()`, which defaults to `record.save()`. For a new leave request, this triggered `hr.leave.create()`'s validation logic, auto-confirming (or even auto-approving) the request before the user had finished the wizard.

This premature save was also the root cause of two related bugs, both fixed as a side effect: closing the Time Type dialog threw `TypeError: Cannot read properties of undefined (reading 'focus')` (the save re-rendered the parent, leaving `Many2One`'s `onClose` pointing at a stale component), and that crash aborted the promise chain before it could reload the calendar, leaving a newly-created leave request missing from view until a manual refresh.

Adds a `many2one_no_save` field widget overriding
`willOpenRecordInDialog` to skip the save, applied to `work_entry_type_id` on the base `hr_leave_view_form` so all inheriting views are covered.

task-6452848

Currently, an error occurs when updating the quantity of an SOL in the portal.

**Steps to Reproduce:**
 - Install the `sale_management` module.
 - Go to `Settings` and enable `Pricelists` under Pricing.
 - Go to `Sales` > `Orders` > `Orders` and create a `sale order`.
 - Add an `order line` of type `Section`, click the `three-dot` menu on the line, and click `Set Optional`.
 - Add another line using `Add a line` and enter only the `description` in that line.
 - Save the `order` and click `Preview`.
 - `Increase` the quantity of the line using the + icon.

`ValueError: Expected singleton: product.product()`

After [recent commit], support for productless Sale Order Lines was added, allowing users to 
create quotation/invoice lines directly from descriptions without requiring a product. 
After [this commit], when updating the quantity of a productless SOL in the portal, the price is 
updated based on the pricelist [1]. While getting the pricelist price [2] for the SOL, the product 
is ensured on the SOL, which raises the error [3] because the SOL does not have a product.

This commit ensures that the unit price is updated based on the pricelist only if the line contains a product.

[recent commit]: https://github.com/odoo/odoo/commit/d069ce59e28fda2bc25fb89fd01ee7b988a30fa0

[this commit]: https://github.com/odoo/odoo/commit/86d40fe5c5ad32af0ceca7cd384b96a8a2f4adc3

[1]- https://github.com/odoo/odoo/blob/e940a655aba06adc784008b72a3917170fdb3dd0/addons/sale_management/controllers/portal.py#L68-L69

[2]- https://github.com/odoo/odoo/blob/e940a655aba06adc784008b72a3917170fdb3dd0/addons/sale/models/sale_order_line.py#L783

[3]- https://github.com/odoo/odoo/blob/e940a655aba06adc784008b72a3917170fdb3dd0/addons/sale/models/sale_order_line.py#L801

sentry-7665145989

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

## Description

When a CI/NIE number fails the check digit validation, the raised error suggests `3:402.010-2 or 93:402.010-1 (CI or NIE)` as the expected format. This is misleading for two reasons:

- The colon notation comes from Uruware's technical manual and is not how identity card numbers are written in Uruguay: users write `3.402.010-1` or plain digits (`34020101`). Real users facing the error keep reformatting a number whose check digit is simply wrong, believing the problem is the format.
- The CI example shown is itself an **invalid** number: the check digit of `3.402.010` is `1`, not `2` — the module's own test suite (`l10n_uy/tests/test_check_vat.py`) uses `3:402.010-2` as an invalid sample.

This was reported by an Uruguayan eCommerce user who lost sales because buyers interpreted the message as requiring an unusual format that does not exist in Uruguay.

## Change

Replace the examples with valid numbers written in the notations actually used in Uruguay, and clarify that separators are optional — which is exactly what `_l10n_uy_ci_nie_is_valid()` already accepts (it strips `:. ,-` before checking the verification digit):

```
3.402.010-1 or 34020101 (CI), 93.402.010-1 (NIE); dots and dash are optional
```

Only the `expected_format` string changes; the validation logic is untouched. Existing tests only assert the fixed part of the message (`The CI/NIE number.*does not seem to be valid`), so they are unaffected.

Forward-Port-Of: odoo/odoo#282489

**Steps to reproduce:**
1. Install the sale module with demo data.
2. Open a sale order and add a combo product (e.g. "Office Combo").
3. Note the displayed untaxed amount on the combo item lines (e.g. 160.00).
4. Switch the document tax mode from "Tax Excl." to "Tax Incl." using the toggle at the top of the Order Lines tab.

**Issue:**
- After switching to "Tax Incl." mode, the total on the sale order is higher than the previous untaxed amount (e.g. shows 266.00 instead of the 160.00).
- The same switch works correctly on regular (non-combo) product lines

**Expected behavior:**
- the new total should equal the previous untaxed amount.

**Why this happens:**
- `_onchange_order_line` is triggered on every `order_line` change, including when switching `document_tax_mode` causes `price_subtotal` to update on existing lines.
- The unconditional write to `product_uom_qty` and `discount` on all combo item lines was calling '_compute_price_unit` even when neither value had changed.
- `_compute_price_unit` then called `_reset_price_unit` under the new `document_tax_mode`, which re-calculated the stored `price_unit` instead of leaving it untouched for `_compute_amount` to reinterpret correctly.

**Fix:**
- Only sync `product_uom_qty` and `discount` to the combo item lines whose current values actually differ from the parent line. When no value has changed, no write occurs, so `_compute_price_unit` is not called.

opw-6427963

Steps to reproduce:
- Make sure you have 2 or more languages installed
- Install events and website app
- For the website, apply the languages you have in settings
- Make sure website default language is different from backend language
- Create an event
- Go to the event's website page through the smart button
- Switch the language of the frontend to one that is different from backend
- Translate (alter) the description for this language
- Click on the outlook icon to download the ics

Current Behavior:
The ics will contain a description based on the backend's chosen language

Expected Behavior:
The ics will contain a description based on the website's chosen language.
If there's no website, it will use the browser's language

Clarification:
The current behavior is confusing for users as they will expect the ics to match
the description of the current webpage which is dependent on the frontend's
selected language. This current behavior also contradicts the google calendar
behavior which grabs the description based on the frontend's selected language.

The endpoints for retrieving the ics file now utilize the website=True flag to
take advantage of IrHttp._match which will automatically set the context
language to be the frontend's rather than the backend language. We want
the ics file to be in the frontend language for visual consistency. Also,
send_email_reminder function does not require with context for this reason

opw-6235320

Forward-Port-Of: odoo/odoo#280520
Forward-Port-Of: odoo/odoo#271968

### Current behavior:
When exporting a quotation PDF from the Sales Order a multi-word product name, e.g. "Pick Up", is split into 2 lines

### Expected behavior:
When exporting a quotation PDF from the Sales Order a multi-word product name, e.g. "Pick Up", should stay on a single line when there is enough horizontal space in the Description column

### Steps to reproduce:
1. Sales > new Sales Order
2. Add a product whose name has at least two words, e.g. "Pick Up"
3. Export the Sales Order report to PDF
4. Observe the second word is pushed to a new line, even with free horizontal space

### Cause of the issue:
Commit https://github.com/odoo/odoo/commit/6d695e53743a58560a00c163b3ac16ee1f149761 added a `d-flex` in 19.3 to keep product image and name on the same line. The `o_product_name_cell` uses default shrink wrap. Under wkhtmltopdf's old QtWebKit engine the shrink-wrapped width is computed marginally short of the real text width; this margin is font-metric dependent, so with the slightly wider font like Open Sans the last word crosses the boundary and wraps onto a new line, even though the surrounding cell has room.

### Fix:
- Add the Bootstrap `flex-grow-1` utility class to the o_product_name_cell div so it grows to fill the remaining width of the flex row
-  The image keeps its fixed 48px width and stays on the same line
- Small UI change, so no unit test. Only manual test:

Before:
<img width="357" height="211" alt="image" src="https://github.com/user-attachments/assets/29458867-c7d0-4cc8-8397-4c97b7a2b91d" />

After:
<img width="342" height="196" alt="image" src="https://github.com/user-attachments/assets/9a1ca99c-916f-4179-b9b9-67879885e9d8" />


opw-6434410

**Steps to reproduce**
- Open any MO
- Click on 'catalog'
- Click on the three dots button of any product
- Try to edit
-> Traceback: `"product.product"."state" field is undefined.`

**Cause**
The `move_raw_ids` field on the MO form sets a context with `form_view_ref: 'mrp.view_mrp_stock_move_operations'`, so that editing a component's `stock.move` line in place opens that dedicated view: https://github.com/odoo/odoo/blob/20db2910d16fa6ebd07794fb9ed3fb1c8f57b0fc/addons/mrp/views/mrp_production_views.xml#L411-L417 The 'Catalog' button lives inside that same field, and calls `action_add_from_catalog_raw`, which delegates to the mixin's `action_add_from_catalog`: https://github.com/odoo/odoo/blob/3dd41395e2e4205fa477eb474d4a4dba0a976154/addons/product/models/product_catalog_mixin.py#L17 Which conserve the `'form_view_ref'` from context: https://github.com/odoo/odoo/blob/3dd41395e2e4205fa477eb474d4a4dba0a976154/addons/product/models/product_catalog_mixin.py#L28 and that action requests its form view with `view_id=False`: https://github.com/odoo/odoo/blob/3dd41395e2e4205fa477eb474d4a4dba0a976154/addons/product/models/product_catalog_mixin.py#L25 Which will try to load `view_mrp_stock_move_operations`, since: https://github.com/odoo/odoo/blob/3dd41395e2e4205fa477eb474d4a4dba0a976154/odoo/addons/base/models/ir_ui_view.py#L3002-L3005 `_get_view` never checks that the resolved view's `model` matches the model it was asked for, so it returns `view_mrp_stock_move_operations`for the `product.product` model: https://github.com/odoo/odoo/blob/3dd41395e2e4205fa477eb474d4a4dba0a976154/addons/mrp/views/stock_move_views.xml#L41 https://github.com/odoo/odoo/blob/3dd41395e2e4205fa477eb474d4a4dba0a976154/addons/stock/views/stock_move_views.xml#L128 `state` doesn't exist on `product.product`, hence the crash.

opw-6433620

Forward-Port-Of: odoo/odoo#279811

# How to reproduce
- Enable dev mode
- In the website editor, add a Video Inner Content to the page
- Enable atleast one option that is not "Start at"
(e.g. Autoplay)
- Click on the Video, and in the Style tab, click on Replace

# The problem
A traceback is shown

# Cause
When you replace a video, a pop up appears with the different options
associated to that video. These options are rendered with the
`VideoOption` component :
https://github.com/odoo/odoo/blob/46d3fee5812b8406aac2244baa76b0daeef358c2/addons/html_editor/static/src/main/media/media_dialog/video_selector.js#L9

The props for that component accept a `value`, which type has been
changed from `Boolean` to `String` in :
https://github.com/odoo/odoo/commit/ae894892e048bcdf9c3efcf41b53b44f2fd9e88b

The issue is that some option's value are defined as boolean :
https://github.com/odoo/odoo/blob/46d3fee5812b8406aac2244baa76b0daeef358c2/addons/html_editor/static/src/main/media/media_dialog/video_selector.js#L352

So the props validation fail, but only in dev mode :
https://github.com/odoo/odoo/blob/46d3fee5812b8406aac2244baa76b0daeef358c2/addons/web/static/lib/owl/owl.js#L3227-L3231

# Proposed solution
When changing the options value in the popup, the trucy values are
replaced by "00:00", which is why the traceback only appears when
replacing the video :
https://github.com/odoo/odoo/blob/46d3fee5812b8406aac2244baa76b0daeef358c2/addons/html_editor/static/src/main/media/media_dialog/video_selector.js#L182-L186

We now use the same trucy represetation in `syncOptionsWithUrl()`

opw-6369196

Forward-Port-Of: odoo/odoo#280375
Forward-Port-Of: odoo/odoo#276585

Currently an error occurs when user tries to send a pdf of a invoice to a customer.

Steps to replicate: (Make sure to have `python 3.14.4` and `pypdf=5.4.0`)
- Install `l10n_sa_edi` with demo and switch to `My Saudi Arabia Company`.
- Open invoices and create an invoice with customer and an invoice line.
- Click `Send` > Again Click `Send`.

Error:
```
AttributeError: 'PageObject' object has no attribute 'getObject'
AttributeError: No attribute getObject found in IndirectObject or pointed object
```

- A recent [PR] introduced the old `getObject()` API in the PDF/A conversion code, even though it has been renamed to `get_object()` in the modern pypdf API.
- As PyPDF2 1.x compatibility has already been removed, `getObject()` is no longer available and causes the error to log on the terminal.
- Please refer to [1] and [2].

[PR]: https://github.com/odoo/odoo/pull/281275

[1]: https://github.com/odoo/odoo/pull/248197/files#diff-f3528e61bb9aa2d24d9b57cddafb7429d21216ba29f9dc7e08c92bb617949911L218

[2]: https://pypdf.readthedocs.io/en/stable/meta/changelog-v1.html#details

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

Steps to reproduce
------------------
1. Configure a product with a subcontracted BoM and a subcontractor.
2. Create a purchase order of 10 units for that product and confirm it.
3. Receive the 10 units.
4. On the receipt, use "Return for Exchange" on 3 units and validate both the return and the exchange receipt.

Issue
-----
After the exchange, the 3 units stay in the subcontracting location instead of reaching `WH/Stock`, and the received quantity on the purchase order line stays at 7 instead of 10.

`mrp_subcontracting` overrides `_prepare_move_default_values` to force the move `location_dest_id` to the subcontractor location for every `is_subcontract` move:
https://github.com/odoo/odoo/blob/d9c06a66356dd9d5a50821b8cde6194967353c18/addons/mrp_subcontracting/wizard/stock_picking_return.py#L20-L25
That is correct for the return, but the same override also runs for the exchange re-receipt, an `incoming` picking whose destination should be the stock location from `return_type.default_location_dest_id`:
https://github.com/odoo/odoo/blob/d9c06a66356dd9d5a50821b8cde6194967353c18/addons/stock/wizard/stock_picking_return.py#L137-L153

The exchange move then goes from the subcontracting location back to itself, so validating it nets zero and `WH/Stock` never receives the units. Skipping the override when `new_picking.picking_type_id.code` is `incoming` lets the exchange land in stock.

The received quantity must also count that receipt. `_should_count_for_quantity_received` only counts `supplier` or `transit` sources:
https://github.com/odoo/odoo/blob/d9c06a66356dd9d5a50821b8cde6194967353c18/addons/stock/models/stock_move.py#L330-L331 so the exchange, sourced from the internal subcontracting location,
is skipped while the return still subtracts its quantity. Counting subcontracting-sourced moves:
https://github.com/odoo/odoo/blob/d9c06a66356dd9d5a50821b8cde6194967353c18/addons/mrp_subcontracting/models/stock_move.py#L312-L314 restores `qty_received` to 10.

opw-6410978

Forward-Port-Of: odoo/odoo#282373
Forward-Port-Of: odoo/odoo#279431

### Steps to reproduce:
- Install 'whatsapp', and 'crm_livechat'
- Configure a WhatsApp channel and receive a message to create a conversation in Discuss
- Open the WhatsApp conversation in Discuss
- Click on the 'Create Lead' smart button
- Check the created lead
> The Customer/Contact field is empty

### Cause of Issue:
When a lead is created from a Discuss conversation, `_convert_visitor_to_lead` in `crm_livechat` attempts to set the lead's customer. It does this by checking if the channel has `livechat_customer_partner_ids`. However, in whatsapp discuss conversations, the client is saved in `whatsapp_partner_id` and `livechat_customer_partner_ids` is empty. https://github.com/odoo/odoo/blob/29556fda44b9f1e6cf08129443ca47fa6cda34f9/addons/crm_livechat/models/discuss_channel.py#L54-L64

### Fix:
Kept the fix local to `crm_livechat` and checked whether `whatsapp` is installed before reading `whatsapp_partner_id`, which would otherwise raise an `AttributeError` since `crm_livechat` does not depend on `whatsapp` and vice versa.

opw-6371274

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

### Issue before this commit:
When generating an electronic invoice (e.g., ZUGFeRD/Factur-X) with a 0% tax from a non-EEA supplier (e.g., Switzerland) to an EEA customer (e.g., Germany), the XML tax <ram:CategoryCode> is incorrectly set to 'E' (Exempt) instead of 'G' (Export).

### Steps to reproduce the issue:
1. Download Accounting and l10n_ch
2. Set the VAT for the CH company
3. Create an invoice for a German customer with 0% tax setted (for which you have to set as electronic invoicing the ZUGFeRD template into the Accounting tab of his contact)
4. Send it and see that the tag <ram:CategoryCode> is setted as E instead of G

### Cause of the issue:
The logic assigning the 'G' and 'K' tax category codes was only triggered if the supplier was located within the EEA. If the supplier was outside the EEA, the code bypassed this block entirely and fell back to the default 'E' code for 0% taxes.

### Reason to introduce the fix:
Update the condition to trigger when either the supplier or the customer is in the EEA. This ensures that cross-border transactions involving at least one EEA party correctly evaluate and apply the 'G' (Export outside the EU) category code.  Also the case supplier not in eea with VAT filled in + customer in eea + RC tax with amount != 0 is fixed now (letter G reported instead of S).

### Documentation:
[eInvoicing technical guidance document_v1.pdf](https://github.com/user-attachments/files/30831749/eInvoicing.technical.guidance.document_v1.pdf)


opw-6407399

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

Forward-Port-Of: odoo/odoo#282497
Forward-Port-Of: odoo/odoo#281245

**Steps to reproduce:**
1. Install Sales and payment_authorize modules
2. Enable "Online Payment" in the settings and Configure the payment method to be Authorize.net
3. Create a sale order, confirm it and create the invoice
4. Pay the invoice with an eCheck (ACH) payment method through the Authorize.net provider
5. Wait for the payment to be settled by Authorize.net (_around 24 hours_)
6. Initiate a refund of the payment

**Issue:**
The refund fails with error `E00003: "The 'AnetApi/xml/v1/schema/AnetApiSchema.xsd:cardNumber' element is invalid - The value XX is invalid according to its datatype 'String' - The actual length is less than the MinLength value`

**Expected behavior:**
The refund should be processed successfully regardless of whether the original payment was made by credit card or eCheck (ACH)

**Why this happens:**
- The `refund()` method in `AuthorizeAPI` builds the refund request using a `creditCard` payment payload
- When the original transaction was an ACH/eCheck payment, the `creditCard` key is absent from the transaction details returned by Authorize.net
- The resulting request is rejected by Authorize.net because it does not satisfy the minimum length constraint for `cardNumber`

**Fix:**
- Detects whether the original payment used `creditCard` or `bankAccount`
from the transaction details and build the appropriate payload according
to Authorize.net API documentation: https://developer.authorize.net/api/reference/index.html#payment-transactions-credit-a-bank-account

opw-6359726

Forward-Port-Of: odoo/odoo#277742

### Steps to reproduce:

- Create a product with a bom and 2 operations
- Create an MO for 1 unit of that product
- Confirm the MO
- On the bom, delete the second operation and modify the first operation on anything else than the company, name or workcenter
- Go back to the MO, click the "Update Bom" button
> The second operation is not unlinked and the first operation is not updated

### Cause of the issue:

The `action_update_bom` updates the move raws and operations of the MO via the `_link_bom`:
https://github.com/odoo/odoo/blob/f66614193cce18f5a3298d03ce7e5f29d54f07e9/addons/mrp/models/mrp_production.py#L1214-L1218 For draft MO's all the work of these updates is done via the compute methods and by deleting all the records unrelevant to the new bom: https://github.com/odoo/odoo/blob/f66614193cce18f5a3298d03ce7e5f29d54f07e9/addons/mrp/models/mrp_production.py#L2603-L2626 And, in that case all the workorders that are not linked to an operation of the bom are expected to be deleted. However, when the MO is not in draft, the update of operations is expected to be performed here: https://github.com/odoo/odoo/blob/f66614193cce18f5a3298d03ce7e5f29d54f07e9/addons/mrp/models/mrp_production.py#L2647-L2664 However, since the operation of the bom has been deleted, the workorder that is expected to be deleted is not linked to any operation and hence does not satisfy the condition to be deleted:
https://github.com/odoo/odoo/blob/f66614193cce18f5a3298d03ce7e5f29d54f07e9/addons/mrp/models/mrp_production.py#L2663-L2664
Concerning the non update of operations, it happens because the MO's operation are only updated on the three fields: `company_id`,
`workcenter_id`, `name`:
https://github.com/odoo/odoo/blob/31df5033e31c193b4576ef37dfbc5fc683817bc5/addons/mrp/models/mrp_production.py#L2647-L2664
https://github.com/odoo/odoo/blob/31df5033e31c193b4576ef37dfbc5fc683817bc5/addons/mrp/models/mrp_production.py#L2628-L2629
However, many other changes can and are actually relevant.

### Note:

Prior to commit 80e6ed658fb43584bc2fad673ca40d9af6cf0ab6 operations were archived on boms rather than deleted:
https://github.com/odoo/odoo/blob/4a5270218fe6fd7d30edb6d684b3340dc7423bab/addons/mrp/views/mrp_routing_views.xml#L53-L55 As such they would still be linked to an operation (but unrelated to the present values of the bom) and hence would fall into the condition of being unlinked from the MO.

Since the bom operations are no longer archived there is no way to determine if an operation used to be linked to a bom and we therefore need to chose between deleting all operations unrelated to the present bom or to keep them all (when the MO has been confirmed).

Enterprise: https://github.com/odoo/enterprise/pull/120709

opw-6285878
opw-6261738

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

Forward-Port-Of: odoo/odoo#280803
Forward-Port-Of: odoo/odoo#269747

## Description

When a CI/NIE number fails the check digit validation, the raised error suggests `3:402.010-2 or 93:402.010-1 (CI or NIE)` as the expected format. This is misleading for two reasons:

- The colon notation comes from Uruware's technical manual and is not how identity card numbers are written in Uruguay: users write `3.402.010-1` or plain digits (`34020101`). Real users facing the error keep reformatting a number whose check digit is simply wrong, believing the problem is the format.
- The CI example shown is itself an **invalid** number: the check digit of `3.402.010` is `1`, not `2` — the module's own test suite (`l10n_uy/tests/test_check_vat.py`) uses `3:402.010-2` as an invalid sample.

This was reported by an Uruguayan eCommerce user who lost sales because buyers interpreted the message as requiring an unusual format that does not exist in Uruguay.

## Change

Replace the examples with valid numbers written in the notations actually used in Uruguay, and clarify that separators are optional — which is exactly what `_l10n_uy_ci_nie_is_valid()` already accepts (it strips `:. ,-` before checking the verification digit):

```
3.402.010-1 or 34020101 (CI), 93.402.010-1 (NIE); dots and dash are optional
```

Only the `expected_format` string changes; the validation logic is untouched. Existing tests only assert the fixed part of the message (`The CI/NIE number.*does not seem to be valid`), so they are unaffected.

Forward-Port-Of: odoo/odoo#282489

**Step to Reproduce:**

1. Create a database in 18.0 with `l10n_mt` installed.
2. Select the Malta chart template (COA).
3. Upgrade the database to 19.0.
4. Verify the tax grids.

**Issue:**

Tax grids remain unchanged after the upgrade and do not reflect the modifications introduced in [1].

The tax definitions are loaded from CSV data and don't happen during upgrade or module update it did through try_loading". Since the account tags already exist in upgraded databases, the changes are not applied during module loading and the updated grid assignments are not assigned to taxes.

**Fix:**
Apply the grid update directly through SQL during the upgrade or module update. The change is limited to tax grid assignments and does not require a full tax reload using ``try_loading`` or ``load_data``.

**Before fix:**
<img width="1458" height="724" alt="image" src="https://github.com/user-attachments/assets/eaac5e3f-d551-4ec0-b282-bb39a50438f9" />

**After fix:**
<img width="1240" height="583" alt="image" src="https://github.com/user-attachments/assets/74409c53-dce0-45b2-a6b5-e60f5c2d826d" />



Note: why this fix is needed because existing upgrade script do update move line grid but still tax have the old grid which is weird and will cause issue when journal entry will create. 

[1]:  https://github.com/odoo/odoo/pull/254894/changes/8921186850e31c53072d49a5dc760192f3edb902

opw-6325845
upg-4391393

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

Forward-Port-Of: odoo/odoo#272038

Problem: When using the many2many_avatar_user widget (such as in the Live Chat app), the badge displaying the number of hidden tags overflows if the count reaches double digits (e.g., "+10"). This causes the text to get cut off, making the exact number unreadable.

Solution: This commit updates the badge container to properly accommodate larger numbers. The text now fits entirely within the badge without overflowing, ensuring the hidden tag count remains fully readable.

Steps to reproduce (runbot v19.3):
1. Open the Live Chat app (or any view using the many2many_avatar_user widget).
2. Add enough agents to a session so the remaining count hits double digits (10 or more).
3. Observe that the badge showing the remaining agent count (e.g., "+10") overflows the badge container, cutting off the text and making it unreadable.

opw-6453976
<img width="2655" height="1111" alt="avatar_tag_193_before" src="https://github.com/user-attachments/assets/9c31007d-5300-4bb7-a703-01a13b5bdd10" />
<img width="2655" height="1112" alt="avatar_tag_193_after" src="https://github.com/user-attachments/assets/7b2a4074-3738-4a6c-9649-f6652601f3f3" />

Steps to reproduce
------------------
1. Configure a product with a subcontracted BoM and a subcontractor.
2. Create a purchase order of 10 units for that product and confirm it.
3. Receive the 10 units.
4. On the receipt, use "Return for Exchange" on 3 units and validate both the return and the exchange receipt.

Issue
-----
After the exchange, the 3 units stay in the subcontracting location instead of reaching `WH/Stock`, and the received quantity on the purchase order line stays at 7 instead of 10.

`mrp_subcontracting` overrides `_prepare_move_default_values` to force the move `location_dest_id` to the subcontractor location for every `is_subcontract` move:
https://github.com/odoo/odoo/blob/d9c06a66356dd9d5a50821b8cde6194967353c18/addons/mrp_subcontracting/wizard/stock_picking_return.py#L20-L25
That is correct for the return, but the same override also runs for the exchange re-receipt, an `incoming` picking whose destination should be the stock location from `return_type.default_location_dest_id`:
https://github.com/odoo/odoo/blob/d9c06a66356dd9d5a50821b8cde6194967353c18/addons/stock/wizard/stock_picking_return.py#L137-L153

The exchange move then goes from the subcontracting location back to itself, so validating it nets zero and `WH/Stock` never receives the units. Skipping the override when `new_picking.picking_type_id.code` is `incoming` lets the exchange land in stock.

The received quantity must also count that receipt. `_should_count_for_quantity_received` only counts `supplier` or `transit` sources:
https://github.com/odoo/odoo/blob/d9c06a66356dd9d5a50821b8cde6194967353c18/addons/stock/models/stock_move.py#L330-L331 so the exchange, sourced from the internal subcontracting location,
is skipped while the return still subtracts its quantity. Counting subcontracting-sourced moves:
https://github.com/odoo/odoo/blob/d9c06a66356dd9d5a50821b8cde6194967353c18/addons/mrp_subcontracting/models/stock_move.py#L312-L314 restores `qty_received` to 10.

opw-6410978

Forward-Port-Of: odoo/odoo#282373
Forward-Port-Of: odoo/odoo#279431

# How to reproduce
- Enable dev mode
- In the website editor, add a Video Inner Content to the page
- Enable atleast one option that is not "Start at"
(e.g. Autoplay)
- Click on the Video, and in the Style tab, click on Replace

# The problem
A traceback is shown

# Cause
When you replace a video, a pop up appears with the different options
associated to that video. These options are rendered with the
`VideoOption` component :
https://github.com/odoo/odoo/blob/46d3fee5812b8406aac2244baa76b0daeef358c2/addons/html_editor/static/src/main/media/media_dialog/video_selector.js#L9

The props for that component accept a `value`, which type has been
changed from `Boolean` to `String` in :
https://github.com/odoo/odoo/commit/ae894892e048bcdf9c3efcf41b53b44f2fd9e88b

The issue is that some option's value are defined as boolean :
https://github.com/odoo/odoo/blob/46d3fee5812b8406aac2244baa76b0daeef358c2/addons/html_editor/static/src/main/media/media_dialog/video_selector.js#L352

So the props validation fail, but only in dev mode :
https://github.com/odoo/odoo/blob/46d3fee5812b8406aac2244baa76b0daeef358c2/addons/web/static/lib/owl/owl.js#L3227-L3231

# Proposed solution
When changing the options value in the popup, the trucy values are
replaced by "00:00", which is why the traceback only appears when
replacing the video :
https://github.com/odoo/odoo/blob/46d3fee5812b8406aac2244baa76b0daeef358c2/addons/html_editor/static/src/main/media/media_dialog/video_selector.js#L182-L186

We now use the same trucy represetation in `syncOptionsWithUrl()`

opw-6369196

Forward-Port-Of: odoo/odoo#280375
Forward-Port-Of: odoo/odoo#276585

Before this commit, decreasing the quantity of a move whose move lines are expressed in another unit of measure removed the wrong quantity from the lines, because the two conversions between the move unit and the line unit converted a value to its own unit, hence did nothing.

Steps to reproduce:
- create a product in Units with available stock
- create a delivery for 2 Dozen of it and mark it as todo
- in the detailed operations, change the unit of the move line to Units (24)
- lower the move quantity from 2 to 1 Dozen

The move line ends up with 23 Units instead of 12: the decrease of 1 Dozen is applied as 1 Unit on the line and considered fully processed. The remaining 11 units stay reserved and counted on the transfer.

Convert the remaining decrease from the move unit to the line unit when taking it from a line, and the taken quantity back to the move unit when updating the remaining decrease.

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

Forward-Port-Of: odoo/odoo#278148
Forward-Port-Of: odoo/odoo#276774

Steps to reproduce:
---
- Install `website_sale` module.
- Enable `Product Variants` and `Prevent Sale of Zero Priced Product` in settings.
- Create new attribute > set `Variant Creation` as `Never` and also add value with extra price.
- Create a product with sales price = 0, assign the attribute, and publish it.
- As a public user (incognito), try to add the product to the cart.

Issue:
---
- In terminal error `The given product does not exist therefore it cannot be added to cart` is raised.

Root cause:
---
- In `_is_add_to_cart_allowed()`[1], the method calls `_get_contextual_price()` [2] to check if the product's price is zero when `prevent_zero_price_sale` is enabled.
- However, `_get_contextual_price()` is called without the no-variant attribute values in the context, so it does not account for their `price_extra`. For a product with list price as 0 and attribute with extra price, the price is incorrectly computed as 0, causing `_is_add_to_cart_allowed()` to return `False`.

Solution:
---
- Before calling `_is_add_to_cart_allowed()`, set the product's context with the no-variant attribute values via `_get_product_price_context()`, so that `_get_contextual_price()` correctly includes the price extra in its computation.

[1]https://github.com/odoo/odoo/blob/bbafbbd8950ec7123ab652851ede5479484eee26/addons/website_sale/controllers/cart.py#L117-L120

[2]https://github.com/odoo/odoo/blob/bbafbbd8950ec7123ab652851ede5479484eee26/addons/website_sale/models/product_product.py#L149-L150

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

Forward-Port-Of: odoo/odoo#278620

### Issue:
In 19.3, the following hoot tests fail with a RunBot error:
- "called at right time (when canceling order)"
- "called at right time (when canceling order never sent to blackbox)"
- "called at right time (when canceling a combo order)"

### Cause:
Commit 0dfd71b9f4 removed `close` from `ControlButtonsPopup` as the Dialog patch now handles closing via `this.data.close()` With no remaining props to declare, `static props` was removed entirely

Without `static props`, Owl skips all prop validation but emits: "Component 'ControlButtonsPopup' does not have a
static props description"
`mountWithCleanup` forces `warnIfNoStaticProps` to `true` in hoot tests, causing the tests to fail

`close` is declared as optional since `dialog_service.js` always injects it via `subProps: markRaw({ ...props, close })` at runtime, but the component no longer uses it directly

### Steps to reproduce:
- Install `l10n_be_pos_blackbox`
- Enable Developer mode
- Open the JS test UI
- Run one of the failing tests

runbot-941231

Steps to reproduce:
- Install Point of Sale without the Restaurant module
- Open a session and scan the barcode of a product

Issue:
The product is never added to the order, the client crashes with "TypeError: this.pos.autoCourseAllocation is not a function".

Cause:
b86126bbfb17105323a8ac972cb5062b95325fc4 moved autoCourseAllocation and cleanAutoCourseAllocation out of ProductScreen (point_of_sale) into the PosStore patch of pos_restaurant, but kept the two call sites in point_of_sale's ProductScreen._barcodeProductAction, now routed through this.pos. Both methods therefore only exist when pos_restaurant is installed, so on a plain shop configuration the call throws. The other call site, ProductScreen.addProductToOrder, is patched in pos_restaurant itself, which is why only the barcode path is affected. Runbot installs every module, so the patch is always loaded there and the crash went unnoticed.

Also restore the argument forwarding in the pos_restaurant PosOrder.removeOrderline patch introduced by the same commit: it declares deep but called super.removeOrderline(line), dropping it. PosStore.breakCombo is the only caller passing deep=false.

opw-6478112

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

Steps to reproduce
------------------
1. Configure a product with a subcontracted BoM and a subcontractor.
2. Create a purchase order of 10 units for that product and confirm it.
3. Receive the 10 units.
4. On the receipt, use "Return for Exchange" on 3 units and validate both the return and the exchange receipt.

Issue
-----
After the exchange, the 3 units stay in the subcontracting location instead of reaching `WH/Stock`, and the received quantity on the purchase order line stays at 7 instead of 10.

`mrp_subcontracting` overrides `_prepare_move_default_values` to force the move `location_dest_id` to the subcontractor location for every `is_subcontract` move:
https://github.com/odoo/odoo/blob/d9c06a66356dd9d5a50821b8cde6194967353c18/addons/mrp_subcontracting/wizard/stock_picking_return.py#L20-L25
That is correct for the return, but the same override also runs for the exchange re-receipt, an `incoming` picking whose destination should be the stock location from `return_type.default_location_dest_id`:
https://github.com/odoo/odoo/blob/d9c06a66356dd9d5a50821b8cde6194967353c18/addons/stock/wizard/stock_picking_return.py#L137-L153

The exchange move then goes from the subcontracting location back to itself, so validating it nets zero and `WH/Stock` never receives the units. Skipping the override when `new_picking.picking_type_id.code` is `incoming` lets the exchange land in stock.

The received quantity must also count that receipt. `_should_count_for_quantity_received` only counts `supplier` or `transit` sources:
https://github.com/odoo/odoo/blob/d9c06a66356dd9d5a50821b8cde6194967353c18/addons/stock/models/stock_move.py#L330-L331 so the exchange, sourced from the internal subcontracting location,
is skipped while the return still subtracts its quantity. Counting subcontracting-sourced moves:
https://github.com/odoo/odoo/blob/d9c06a66356dd9d5a50821b8cde6194967353c18/addons/mrp_subcontracting/models/stock_move.py#L312-L314 restores `qty_received` to 10.

opw-6410978

Forward-Port-Of: odoo/odoo#282373
Forward-Port-Of: odoo/odoo#279431

The JsonFormatter has two bugs

- the ignore list is not working as expected
- in 18.0-18.4 the 'test' key is broken

This commit add tests to ensure those behavior works as expected

While on it, also adds a `additional_record_keys` parameter to allow to specifically add keys to the default list, without having to override the whole list, and add additional default keys (exc_info and test)

The previous `ignored_record_keys` default value was possible to remove by calling `JSONFormatter(ignore_record_keys=[])`

The purpose was to be able to easily include all keys and ignore the default ingnore list, but this makes the additional blacklisting of a few keys more tedious, and the general usage and implementation more complex

`JSONFormatter(ignore_record_keys=[*JSONFormatter.DEFAULT_IGNORED_RECORD_KEYS, 'other key'])`

To simplify the logic, **this is not the case anymore**, so to include all keys something like this would be needed

`JSONFormatter(additional_record_keys=JSONFormatter.DEFAULT_IGNORED_RECORD_KEYS)`

Or an hardcoded list.

Forward-Port-Of: odoo/odoo#279828
Forward-Port-Of: odoo/odoo#279049

### Issue before this commit:
When generating an electronic invoice (e.g., ZUGFeRD/Factur-X) with a 0% tax from a non-EEA supplier (e.g., Switzerland) to an EEA customer (e.g., Germany), the XML tax <ram:CategoryCode> is incorrectly set to 'E' (Exempt) instead of 'G' (Export).

### Steps to reproduce the issue:
1. Download Accounting and l10n_ch
2. Set the VAT for the CH company
3. Create an invoice for a German customer with 0% tax setted (for which you have to set as electronic invoicing the ZUGFeRD template into the Accounting tab of his contact)
4. Send it and see that the tag <ram:CategoryCode> is setted as E instead of G

### Cause of the issue:
The logic assigning the 'G' and 'K' tax category codes was only triggered if the supplier was located within the EEA. If the supplier was outside the EEA, the code bypassed this block entirely and fell back to the default 'E' code for 0% taxes.

### Reason to introduce the fix:
Update the condition to trigger when either the supplier or the customer is in the EEA. This ensures that cross-border transactions involving at least one EEA party correctly evaluate and apply the 'G' (Export outside the EU) category code.  Also the case supplier not in eea with VAT filled in + customer in eea + RC tax with amount != 0 is fixed now (letter G reported instead of S).

### Documentation:
[eInvoicing technical guidance document_v1.pdf](https://github.com/user-attachments/files/30831749/eInvoicing.technical.guidance.document_v1.pdf)


opw-6407399

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

Forward-Port-Of: odoo/odoo#282497
Forward-Port-Of: odoo/odoo#281245

Steps to reproduce:
- Make sure you have 2 or more languages installed
- Install events and website app
- For the website, apply the languages you have in settings
- Make sure website default language is different from backend language
- Create an event
- Go to the event's website page through the smart button
- Switch the language of the frontend to one that is different from backend
- Translate (alter) the description for this language
- Click on the outlook icon to download the ics

Current Behavior:
The ics will contain a description based on the backend's chosen language

Expected Behavior:
The ics will contain a description based on the website's chosen language.
If there's no website, it will use the browser's language

Clarification:
The current behavior is confusing for users as they will expect the ics to match
the description of the current webpage which is dependent on the frontend's
selected language. This current behavior also contradicts the google calendar
behavior which grabs the description based on the frontend's selected language.

The endpoints for retrieving the ics file now utilize the website=True flag to
take advantage of IrHttp._match which will automatically set the context
language to be the frontend's rather than the backend language. We want
the ics file to be in the frontend language for visual consistency. Also,
send_email_reminder function does not require with context for this reason

opw-6235320

Forward-Port-Of: odoo/odoo#271968

## Description

When a CI/NIE number fails the check digit validation, the raised error suggests `3:402.010-2 or 93:402.010-1 (CI or NIE)` as the expected format. This is misleading for two reasons:

- The colon notation comes from Uruware's technical manual and is not how identity card numbers are written in Uruguay: users write `3.402.010-1` or plain digits (`34020101`). Real users facing the error keep reformatting a number whose check digit is simply wrong, believing the problem is the format.
- The CI example shown is itself an **invalid** number: the check digit of `3.402.010` is `1`, not `2` — the module's own test suite (`l10n_uy/tests/test_check_vat.py`) uses `3:402.010-2` as an invalid sample.

This was reported by an Uruguayan eCommerce user who lost sales because buyers interpreted the message as requiring an unusual format that does not exist in Uruguay.

## Change

Replace the examples with valid numbers written in the notations actually used in Uruguay, and clarify that separators are optional — which is exactly what `_l10n_uy_ci_nie_is_valid()` already accepts (it strips `:. ,-` before checking the verification digit):

```
3.402.010-1 or 34020101 (CI), 93.402.010-1 (NIE); dots and dash are optional
```

Only the `expected_format` string changes; the validation logic is untouched. Existing tests only assert the fixed part of the message (`The CI/NIE number.*does not seem to be valid`), so they are unaffected.

Forward-Port-Of: odoo/odoo#282489

**Steps to reproduce:**
* Create a **French** parent company and a branch.
* Activate **Electronic Invoicing (PDP)** for the parent company.
* Switch to the branch while keeping both the **parent company** and the **branch** selected in the company switcher.
* Go to **Settings → French Localization → Activate Electronic Invoicing**.
* Activate **Electronic Invoicing (PDP)** for the branch.
* Select the **Participate in the pilot phase** checkbox and try to save settings.

**Observed behavior:**
* A traceback occurs with the error: `psycopg2.errors.SyntaxError: syntax error at or near ")"` on `IN ()` in the SQL query inside `_force_update_l10n_fr_f10_moves`.

**Cause:**
* `_force_update_l10n_fr_f10_moves` searches for receivable/payable accounts using `company_ids IN companies.ids`.
* A branch company has no accounts assigned directly to it — accounts belong to the parent company — so the search returns an empty list.
* Passing an empty tuple to `IN %(account_ids)s` generates `IN ()`, which is invalid PostgreSQL syntax.

**Fix:**
* Replace `('company_ids', 'in', companies.ids)` with
  `('company_ids', 'parent_of', companies.ids)` in the account search
  inside `_force_update_l10n_fr_f10_moves`.
* This ensures that accounts owned by a parent company are correctly
  found when the given companies are branches, since branch companies
  inherit their parent's chart of accounts.

opw-6394650

Forward-Port-Of: odoo/odoo#277232

Steps to Reproduce:

1. Confirm a Sales Order with one line -> creates delivery P1. Validate P1 with date_done = Day_A.
2. Create an invoice from the SO and post it -> invoice.delivery_date = Day_A.
3. Add a new line to the same SO -> creates delivery P2.
4. Validate P2 with date_done = Day_B, where Day_B is earlier than Day_A.

Issue:
The already-posted invoice's `delivery_date` silently changes from Day_A to Day_B after step 4, even though nobody edited the invoice. This only happens when a delivery validated after posting has an earlier `date_done` than what was already used.

Root Cause:
`account.move.delivery_date (sale_stock)` is computed in `_compute_delivery_date()`, which depends on `sale.order.effective_date.effective_date` is itself computed as the earliest `date_done` among all done, facing deliveries on the order. Neither compute method checks whether the invoice is posted, so validating P2 triggers a chain reaction: the delivery is saved -> the sale order recalculates -> the invoice recalculates -> delivery_date gets overwritten on an already-posted invoice.

`sale_stock` also marks `delivery_date` as protected, but this protection only works when the invoice itself is saved (write/create). Here, the change starts from saving the delivery (stock.picking), which never goes through the invoice's save method, so the protection never kicks in. `delivery_date` is also not on the list of fields Odoo normally blocks from editing after posting.

Fix:
`_compute_delivery_date()` now splits invoices into posted and non-posted before running. Non-posted invoices work exactly as before. Posted invoices are skipped from the sync and simply keep their current value instead of taking the newly calculated one. `sale.order.effective_date` itself is untouched only its effect on an already-posted invoice is blocked.

Result:
Once an invoice is posted, its `delivery_date` now stays fixed no matter what happens with later deliveries on the same sale order. `effective_date` keeps updating normally either way, confirming the fix only affects the invoice. Verified with both a script and a manual UI test.

opw-6409171

Forward-Port-Of: odoo/odoo#280978

## Description

When a CI/NIE number fails the check digit validation, the raised error suggests `3:402.010-2 or 93:402.010-1 (CI or NIE)` as the expected format. This is misleading for two reasons:

- The colon notation comes from Uruware's technical manual and is not how identity card numbers are written in Uruguay: users write `3.402.010-1` or plain digits (`34020101`). Real users facing the error keep reformatting a number whose check digit is simply wrong, believing the problem is the format.
- The CI example shown is itself an **invalid** number: the check digit of `3.402.010` is `1`, not `2` — the module's own test suite (`l10n_uy/tests/test_check_vat.py`) uses `3:402.010-2` as an invalid sample.

This was reported by an Uruguayan eCommerce user who lost sales because buyers interpreted the message as requiring an unusual format that does not exist in Uruguay.

## Change

Replace the examples with valid numbers written in the notations actually used in Uruguay, and clarify that separators are optional — which is exactly what `_l10n_uy_ci_nie_is_valid()` already accepts (it strips `:. ,-` before checking the verification digit):

```
3.402.010-1 or 34020101 (CI), 93.402.010-1 (NIE); dots and dash are optional
```

Only the `expected_format` string changes; the validation logic is untouched. Existing tests only assert the fixed part of the message (`The CI/NIE number.*does not seem to be valid`), so they are unaffected.

Forward-Port-Of: odoo/odoo#282489

* = de, din5008, din5008_purchase, din5008_repair, din5008_sale

**Steps to reproduce:**

* Install the **Germany - Accounting** (`l10n_de`) module (which pulls in `l10n_din5008`)
* Set the document layout to **DIN 5008** and generate any PDF report (invoice, quotation, purchase order, etc.).

**Observed behavior (date format):**

* All dates in the information block (Invoice Date, Due Date, Delivery Date, Order Date, etc.) are rendered in `yyyy-mm-dd` format instead of the expected `dd.MM.yyyy` format used in DE, AT, and CH.

**Observed behavior (commercial register):**

* The footer always shows `HRB-Nr.:` regardless of whether the company has a commercial register entry.
* The abbreviation `HRB-Nr.:` appears even for Austrian and Swiss companies, where the commercial register number is a German-specific concept.
* In the company form view, the field is labeled generically as "Company ID" instead of "Commercial Register Number" for German companies.

**Cause (date format):**

* All `t-options="{'widget': 'date'}"` directives across the DIN 5008 template family rely on the active user's language locale for date formatting. If the user language is not `de_DE`, dates render in the locale's default format (e.g. `yyyy-mm-dd` for `en_US`).

**Cause (commercial register):**

* The footer renders `company.company_registry` unconditionally with no country guard and no label.

**Fix (date format):**

* Add `'format': 'dd.MM.yyyy'` explicitly to all `t-options` date widgets across all DIN 5008 report templates (`l10n_din5008`, `l10n_din5008_sale`, `l10n_din5008_purchase`, `l10n_din5008_sale_subscription`, `l10n_din5008_repair`, `l10n_din5008_account_followup`, `l10n_din5008_industry_fsm`).
* This is correct for all three countries using DIN 5008 (DE, AT, CH), which all follow the `dd.MM.yyyy` convention.

**Fix (commercial register):**

* Remove the hardcoded `HRB-Nr.:` label from the footer and instead render `company.partner_id.company_registry_label` (which is country-aware).
* Update the duplicate contact warning message to use the country-aware label via `company.partner_id.company_registry_label`, backed by a new `_get_company_registry_labels` override in l10n_de that registers `Commercial Register Number` for `DE`.
* In the company form view (`l10n_de`), hide the generic "Company ID" field for German companies and show a relabeled instance with `string="Commercial Register Number"` instead.

opw-6392649

Forward-Port-Of: odoo/odoo#279085

Steps to Reproduce:

1. Confirm a Sales Order with one line -> creates delivery P1. Validate P1 with date_done = Day_A.
2. Create an invoice from the SO and post it -> invoice.delivery_date = Day_A.
3. Add a new line to the same SO -> creates delivery P2.
4. Validate P2 with date_done = Day_B, where Day_B is earlier than Day_A.

Issue:
The already-posted invoice's `delivery_date` silently changes from Day_A to Day_B after step 4, even though nobody edited the invoice. This only happens when a delivery validated after posting has an earlier `date_done` than what was already used.

Root Cause:
`account.move.delivery_date (sale_stock)` is computed in `_compute_delivery_date()`, which depends on `sale.order.effective_date.effective_date` is itself computed as the earliest `date_done` among all done, facing deliveries on the order. Neither compute method checks whether the invoice is posted, so validating P2 triggers a chain reaction: the delivery is saved -> the sale order recalculates -> the invoice recalculates -> delivery_date gets overwritten on an already-posted invoice.

`sale_stock` also marks `delivery_date` as protected, but this protection only works when the invoice itself is saved (write/create). Here, the change starts from saving the delivery (stock.picking), which never goes through the invoice's save method, so the protection never kicks in. `delivery_date` is also not on the list of fields Odoo normally blocks from editing after posting.

Fix:
`_compute_delivery_date()` now splits invoices into posted and non-posted before running. Non-posted invoices work exactly as before. Posted invoices are skipped from the sync and simply keep their current value instead of taking the newly calculated one. `sale.order.effective_date` itself is untouched only its effect on an already-posted invoice is blocked.

Result:
Once an invoice is posted, its `delivery_date` now stays fixed no matter what happens with later deliveries on the same sale order. `effective_date` keeps updating normally either way, confirming the fix only affects the invoice. Verified with both a script and a manual UI test.

opw-6409171

Forward-Port-Of: odoo/odoo#280978

### Steps to reproduce

1. Go to `Accounting > Customers > Invoices` and create an invoice on a given journal, leaving it in draft. For the clearest case, leave it with no invoice line.
2. Go to `Accounting > Configuration > Journals`, open that journal and archive it.
3. `_check_auto_post_draft_entries` raises: *"You can not archive a journal containing draft journal entries. To proceed: 1/ click on the top-right button 'Journal Entries' from this journal form 2/ then filter on 'Draft' entries 3/ select them all and post or delete them through the action menu"*.
4. Follow those steps: click the `Journal Entries` smart button on the journal form.

### Current behaviour

The list comes up empty, so the user concludes the error message is wrong, while the draft entries do exist.

The instructions cannot be followed:

- The smart button opens `action_account_moves_all_a`, which is named **"Journal Items"** and targets **`account.move.line`**, not `account.move`. The label of the button and the name of the action it opens do not match.
- That action defaults to `search_default_posted: 1`, so no draft record is listed.
- Draft entries with **no line at all** — commonly created through the incoming mail alias of a journal — have no `account.move.line`, so they stay invisible in that view even after switching the filter.
- The action menu of a move line list offers no way to post or delete the entries, and the action sets `create: 0`.
- The filter is labelled **"Unposted"**, not "Draft".

The offending entries are only reachable through `Accounting > Accounting > Journal Entries`, filtering by journal and by "Unposted".

### Expected behaviour

The error should point to a view where the records blocking the archiving are actually listed and actionable.

### This PR

Message only — the validation itself is unchanged. It now points to `Accounting > Accounting > Journal Entries` and uses the real filter name, "Unposted".

Not addressed here, since it is a UI change rather than a message fix: the root cause is the `Journal Entries` label on a button that opens the `Journal Items` action (`account_journal_views.xml`). Renaming the button to match its action would make the mismatch go away at the source. Happy to add it here if you prefer.

Targeted at 18.0 because that is where the misleading message is being hit in practice; it is identical on 19.0 and master. If a translatable string change does not qualify for the stable series, tell me and I will retarget to master.

> Reopening of https://github.com/odoo/odoo/pull/282286, which GitHub closed automatically after a bad force-push on my side (the branch was pushed from a shallow clone and lost its parent commit). The branch history is fixed and the PR could not be reopened, hence this one. The review discussion is in the previous PR.

### Steps to reproduce

1. Go to `Accounting > Customers > Invoices` and create an invoice on a given journal, leaving it in draft. For the clearest case, leave it with no invoice line.
2. Go to `Accounting > Configuration > Journals`, open that journal and archive it.
3. `_check_auto_post_draft_entries` raises: *"You can not archive a journal containing draft journal entries. To proceed: 1/ click on the top-right button 'Journal Entries' from this journal form 2/ then filter on 'Draft' entries 3/ select them all and post or delete them through the action menu"*.
4. Follow those steps: click the `Journal Entries` smart button on the journal form.

### Current behaviour

The list comes up empty, so the user concludes the error message is wrong, while the draft entries do exist.

The instructions cannot be followed:

- The smart button opens `action_account_moves_all_a`, which is named **"Journal Items"** and targets **`account.move.line`**, not `account.move`. The label of the button and the name of the action it opens do not match.
- That action defaults to `search_default_posted: 1`, so no draft record is listed.
- Draft entries with **no line at all** — commonly created through the incoming mail alias of a journal — have no `account.move.line`, so they stay invisible in that view even after switching the filter.
- The action menu of a move line list offers no way to post or delete the entries, and the action sets `create: 0`.
- The filter is labelled **"Unposted"**, not "Draft".

The offending entries are only reachable through `Accounting > Accounting > Journal Entries`, filtering by journal and by "Unposted".

### Expected behaviour

The error should point to a view where the records blocking the archiving are actually listed and actionable.

### This PR

Two changes, the validation itself is unchanged:

- The error message now points to `Accounting > Accounting > Journal Entries` and uses the real filter name, "Unposted".
- The smart button of the journal form is renamed to **"Journal Items"**, so its label matches the action it opens and no longer suggests it lists journal entries. This was asked for in the review of the previous PR.

Targeted at 18.0 because that is where the misleading message is being hit in practice; it is identical on 19.0 and master. If a translatable string change does not qualify for the stable series, tell me and I will retarget to master.

* = de, din5008, din5008_purchase, din5008_repair, din5008_sale

**Steps to reproduce:**

* Install the **Germany - Accounting** (`l10n_de`) module (which pulls in `l10n_din5008`)
* Set the document layout to **DIN 5008** and generate any PDF report (invoice, quotation, purchase order, etc.).

**Observed behavior (date format):**

* All dates in the information block (Invoice Date, Due Date, Delivery Date, Order Date, etc.) are rendered in `yyyy-mm-dd` format instead of the expected `dd.MM.yyyy` format used in DE, AT, and CH.

**Observed behavior (commercial register):**

* The footer always shows `HRB-Nr.:` regardless of whether the company has a commercial register entry.
* The abbreviation `HRB-Nr.:` appears even for Austrian and Swiss companies, where the commercial register number is a German-specific concept.
* In the company form view, the field is labeled generically as "Company ID" instead of "Commercial Register Number" for German companies.

**Cause (date format):**

* All `t-options="{'widget': 'date'}"` directives across the DIN 5008 template family rely on the active user's language locale for date formatting. If the user language is not `de_DE`, dates render in the locale's default format (e.g. `yyyy-mm-dd` for `en_US`).

**Cause (commercial register):**

* The footer renders `company.company_registry` unconditionally with no country guard and no label.

**Fix (date format):**

* Add `'format': 'dd.MM.yyyy'` explicitly to all `t-options` date widgets across all DIN 5008 report templates (`l10n_din5008`, `l10n_din5008_sale`, `l10n_din5008_purchase`, `l10n_din5008_sale_subscription`, `l10n_din5008_repair`, `l10n_din5008_account_followup`, `l10n_din5008_industry_fsm`).
* This is correct for all three countries using DIN 5008 (DE, AT, CH), which all follow the `dd.MM.yyyy` convention.

**Fix (commercial register):**

* Remove the hardcoded `HRB-Nr.:` label from the footer and instead render `company.partner_id.company_registry_label` (which is country-aware).
* Update the duplicate contact warning message to use the country-aware label via `company.partner_id.company_registry_label`, backed by a new `_get_company_registry_labels` override in l10n_de that registers `Commercial Register Number` for `DE`.
* In the company form view (`l10n_de`), hide the generic "Company ID" field for German companies and show a relabeled instance with `string="Commercial Register Number"` instead.

opw-6392649

### Issue:
When multiple partners share the same email address, `_mail_find_partner_from_emails` may resolve to the wrong partner when the input is a formatted email like "`Name <email>`"

This affects use cases like email templates using `{{object.company_id.email_formatted}}` as sender, where the wrong company partner could be selected

### Cause:
The lookup in `done_partners` only matched on `email_normalized`, which cannot distinguish partners sharing the same email but with different names

The `email_formatted` field carries both name and email, allowing an exact match when the input is a formatted email

### Steps to reproduce:
- Install `account`
- Create an Email Template (Applies to: account.move, From: {{object.company_id.email_formatted}})
- Create a second company B with the same email as the default (e.g. info@yourcompany.com)
- In Settings (logged in as company B), set a Fiscal Position (e.g. US Taxable)
- Create an Invoice on company B
- In the chatter, click Send message, click the expand arrows button, use the three dots menu to select the template
- Send and check the Sender in the chatter

Before the fix, the sender resolves to the default company even though the invoice belongs to company B

opw-6260992

Steps to produce:
---
- Install the `Sales` module.
- In Settings, enable `Automatic Invoice`.
- Also enable the Demo payment provider.
- Create a sale order with a total of `800` and confirm it.
- Generate a payment link for `200` from the gear icon and pay it.
- Generate a second payment link for `300` and pay it.
- Generate a final payment link for the remaining `300` and pay it.

Issue:
---
- After the first payment (200), an `invoice of 200` is created. Correct.
- After the second payment (300), an` invoice of 500` is created instead of 300.
- After the third payment (300), an `invoice of 100` is created instead of 300.

Root cause:
---
- The down payment invoice uses `order.amount_paid`, the cumulative sum of all transactions on the order, instead of the amount of the latest payment. This causes invoices to be sized off the running total instead of the individual payment delta.

Fix:
---
- Compute the invoice amount as `order.amount_paid - order.amount_invoiced` (the unpaid) instead of passing the cumulative `amount_paid` directly.

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

Steps to reproduce the bug:
- Log in as a user with only the "Inventory / User" access right and
Products/Create (product.group_product_manager) granted (write access
to product.product/product.template)

- Open a storable product's form view.
    - Observe the "Quantity On Hand" field is readonly, and the "On Hand"
    quants popup opened from it is read-only too.
- Go to the Inventory > Physical Inventory / Inventory Adjustments menu instead.
    - Observe the same user can freely edit the quantity and apply the inventory adjustment.

Problem:
A stock user could apply inventory adjustments from the Inventory
Adjustments menu, but could not perform the exact same action from
the product form, forcing an unnecessary detour.

Three places in `stock` still gated editing to `stock.group_stock_manager`,
even though `inventory_mode` is already granted to any `stock.group_stock_user`
by `stock.quant._set_view_context()`, and the underlying write is already
guarded correctly by `_is_inventory_mode()`:
- `stock.quant._get_quants_action()` only picks the editable tree view
(used by the "On Hand" quants popup) for managers:
  https://github.com/odoo/odoo/blob/19.0/addons/stock/models/stock_quant.py#L1328
- The product form's own "Quantity On Hand" field/link
(`product_views.xml`) is only made editable for managers, and forced
readonly for everyone else:
  https://github.com/odoo/odoo/blob/19.0/addons/stock/views/product_views.xml#L192-L196
- The `inventory_quantity_auto_apply` field itself (the one actually
rendered in the editable quants list, whether opened from the product
form or the Forecasted Report) is restricted to managers at the Python
field-definition level:
  https://github.com/odoo/odoo/blob/19.0/addons/stock/models/stock_quant.py#L100-L104

All three checks were left over from before commit
https://github.com/odoo/odoo/commit/37d96f49ccc85fa651f092b6c32bab1af2c34f2d,
which gave `stock.group_stock_user` write access on `stock.quant`
(see `ir.model.access.csv`) and dropped the manager-only restriction on
`action_apply_inventory`. The ACL and the Inventory Adjustments flow
were updated at the time, but these three entry points were not, leaving
them stricter than the rest of the permission model.

opw-6439844

Currently, an error occurs when user tries to pay on a vendor bill and removes the currency.

Steps to replicate:
- Install `l10n_account_withholding_tax`and activate multiple currencies.
- Open Invoicing > Vendors > Bills and create a new bill and add a vendor and bill date.
- Add a product and tax `2% WTH`.
- From the Cog menu > Click Pay > Remove the Currency.

Error:
```
  File '/home/odoo/src/odoo/saas-19.4/addons/l10n_account_withholding_tax/models/account_withholding_line.py', line 208, in _compute_original_amounts
    line.original_base_amount = line_curr.round(base_amount * rate)
  File '/home/odoo/src/odoo/saas-19.4/odoo/addons/base/models/res_currency.py', line 264, in round
    self.ensure_one()
  File '/home/odoo/src/odoo/saas-19.4/odoo/orm/models.py', line 5342, in ensure_one
    raise ValueError('Expected singleton: %s' % self)
ValueError: Expected singleton: res.currency()
```

Cause:
- As the user removed currency, the `comodel_currency_id`is received as false.
- Later when we call `round()` on the empty res.currency recordset causes this error to occur.

Solution:
- Added the company currency as a fallback value when `currency_id` is removed by user, since `currency_id` is a required field user will need to select a currency when saving.

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

## Steps to reproduce:

- Enable ship later for the PoS
- Create a product A, tracked by lots
- Create a kit product, include a component A
- Go to the PoS, order this kit product
- Also order the component A
- Tick the ship later option --> A traceback appears

## Why the fix:

With the ship later option activated, we do not compute the lines_data in the same way we do when asking for an invoice.

For the invoice, https://github.com/odoo/odoo/blob/7676723dbb47c09a71925831b13ced97eb855297/addons/point_of_sale/models/stock_picking.py#L37 
We take every stockable line that is positive, but with the ship later option, we only take the lines that are tracked, meaning in this exemple we do not take the Kit line in lines_data. https://github.com/odoo/odoo/blob/7676723dbb47c09a71925831b13ced97eb855297/addons/point_of_sale/models/pos_order.py#L1525-L1532

The result of this is that we do not get the kit line in **_get_lot_line_qty**, explaining the traceback, as we are trying to access it.

Instead of relying on **lines_data** that could change depending on the context, we now use the pos order to fetch the line(s) with our kit product.

Adding the kit line to **lines_data** will most likely result in unwanted changes because lots of operations are done on each of it's items.

opw-6431457

When the FIFO vacuum creates the "Expenses Revaluation" journal entry for an anglo-saxon delivery whose cost is adjusted by a later receipt, the JE was built using `env.company` instead of the company of the vacuumed SVL.

Steps to reproduce:
- Enable multi-company and activate anglo-saxon accounting on two companies A and B.
- In company B, on the product category: set FIFO costing + Automated  valuation, and set the stock input / stock output / stock valuation accounts and the stock journal. The Stock Output account must have "Allow Reconciliation" enabled.
- In company B, on the product: set an Expense Account and set the Cost (e.g. 10.0) this is the price the delivery will be valued at while the stock is negative. The product must have no quantity on hand in company B.
- While working in company B, sell and deliver 1 unit of that product: the delivery is valued at 10.0 and creates a  negative valuation layer.
- Still in company B, create and post the customer invoice of that sale, so the Stock Output line of the delivery entry gets reconciled with the Stock Output line of the anglo-saxon COGS entry of the invoice.
- Switch the active company to A, and from there create a purchase order of that product for company B at a different price (e.g. 15.0), then validate the linked receipt into company B's warehouse.
- The vacuum compensates the negative layer, but the resulting "Expenses Revaluation of ..." journal entry is posted in company A instead of company B.

This fix forces the company context to `vacuum_svl.company_id` when fetching the product accounts and preparing the move lines so the JE is always created in the company of the SVL being vacuumed.

opw-6066970
opw-6419188