A running task/ticket timer can sometimes stutter, show negative values, and track the wrong elapsed time.

### Steps to reproduce

On a record with a timesheet timer (for example, a Field Service task):

1. Start the timer and let it run for about 15-20 seconds.
2. Stop it and confirm the dialog.
3. Start it again. This creates a new `timer_start`.
4. Reload the page.

The timer starts jumping every second between two different values. As it keeps running, it can even show negative values such as `00:00:-57`.

If the problem does not appear right away, repeat steps 2-4 a few times. It usually shows up after a few stop/start/reload cycles.

### Cause

The timer shown in the button bar is the `timer_start_field` widget. It starts a `setInterval` that updates a shared `TimerReactive` object once per second.

While a form is loading, Odoo renders it several times in a row (for example: a first render, another when the chatter is loaded, and another when the record data comes back from the server). Rendering a form builds all of its fields to produce the display, so each of these renders creates its own `timer_start_field`. Odoo keeps and mounts only the render that ends up on screen; the earlier ones are thrown away before being mounted.

The interval is started while the field renders, from the record observer set up in `setup`, before the field is mounted. So the fields that are later thrown away also start an interval. Those intervals keep running for the rest of the session. Each one updates the same shared `TimerReactive` object using the `timer_start` it was created with.

As long as every instance has the same `timer_start`, they all write the same value and the problem stays hidden. After the timer is stopped and started again, the old instances keep the old `timer_start` while the mounted one uses the new one. Every second they overwrite each other's value, so the timer jumps between two different elapsed times. When the instance with the newer `timer_start` writes right after one with an older start, it tries to show a smaller elapsed time than what is already there, and the subtraction in `TimerReactive` produces a negative number of seconds.

### Fix

Move the per-second timer update into a `useEffect`. The effect only runs after the field is mounted, and Owl automatically cleans it up when the field is unmounted or when `timer_start` or `timer_pause` change.

This means fields that are destroyed before they are mounted never start an interval, so only the mounted field updates the shared timer.

`onRecordChange` no longer starts or stops the interval. It only updates the displayed timer value to match the current record.

opw-6209405

Forward-Port-Of: odoo/enterprise#126242

Problem:
On a flexible working schedule, a time off of a few hours (neither a full nor a half day) was treated as a full day off. The Attendance list then reported the whole day's attendance as overtime, and the Time Off gantt grayed out the entire day instead of only the leave's hours.

Steps to reproduce:
1. Give an employee a flexible working schedule (e.g. 8h/day) with an overtime ruleset based on the contract's expected hours.
2. Record a 2-hour time off, then an 8-hour attendance on the same day.
3. Observe the attendance reports 8 hours of overtime instead of 2.

Current behavior:
A partial time off makes the whole day count as extra hours.

Expected behavior:
Only the hours actually taken off reduce the day's expected hours.

Cause:
For a flexible schedule, _handle_flexible_leave_interval expands a leave to the whole day. The override already narrows full-day and half-day leaves, but any other number of hours fell through to that full-day expansion. The expanded interval is subtracted from the day's expected hours in _work_intervals_batch, so they drop to zero and every worked hour becomes overtime.

Fix:
A leave of an arbitrary number of hours should only remove the hours it actually covers, so it keeps its requested interval instead of being stretched to the whole day.

opw-6291536

Forward-Port-Of: odoo/enterprise#127449
Forward-Port-Of: odoo/enterprise#123778

### 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:
Overrode `_convert_visitor_to_lead` in the `whatsapp` module to properly populate the `partner_id` of the created lead if it wasn't already set and the channel has a `whatsapp_partner_id` instead of checking for the client in `crm_livechat`, which will raise an "Attribute Error", since `crm_livechat` isn't dependent on `whatsapp`.

**Note**: No automated test could be added for this fix. Testing the `_convert_visitor_to_lead` method from the `whatsapp` module requires the `crm_livechat` module to be installed to access the base method implementation

opw-6371274

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 cahnges 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).

Community: https://github.com/odoo/odoo/pull/269747

opw-6285878
opw-6261738

Forward-Port-Of: odoo/enterprise#126938
Forward-Port-Of: odoo/enterprise#120709

Steps to Reproduce:
1. Install l10n_do_edi on a company configured with Dominican Republic localization.
2. Leave the company's address / Document Layout details unconfigured (Settings > Companies > Configure Document Layout).
3. Enable 'Use Documents' on the sales journal and create a Customer Invoice with Document Type = Electronic Consumer Invoice (e-CF).
4. Confirm/post the invoice and print/preview the PDF.
5. Observe the company name is printed twice in the header.

Root Cause:
l10n_do_edi.custom_header explicitly renders the company name via:
    [`<span t-field='o.company_id.partner_id.name'/>`](https://github.com/odoo-dev/enterprise/blob/c23d526f53402471dccbbf9460cfd04ce377b5d0/l10n_do_edi/views/report_invoice.xml#L10)

immediately followed by a call to the core template web.company_address_list:
   [` <t t-call='web.company_address_list'/>`](https://github.com/odoo-dev/enterprise/blob/c23d526f53402471dccbbf9460cfd04ce377b5d0/l10n_do_edi/views/report_invoice.xml#L11)

When the company's address/Document Layout is empty, `company.is_company_details_empty` evaluates True, causing `web.company_address_list` to fall back to a contact widget with `fields=['address', 'name']` — which renders the company name a second time. custom_header assumed `company_address_list` would never render the name itself, which does not hold in this empty-address state, resulting in the duplicate. This only surfaces on e-CF document types, since custom_header is only set via l10n_do_edi.report_invoice_document's routing (_get_name_invoice_report()), which standard invoices never hit.

Solution:
Made the explicit name span in `l10n_do_edi.custom_header` conditional on whether the company's details are configured. `web.company_address_list` (core, shared across other reports, left untouched) already renders the company name via its contact widget fallback when the address is empty — so the explicit span now only prints the name when `company_details` is populated, avoiding both sources printing it at once.

Result:
Company name now renders exactly once on e-CF invoices, regardless of whether the company's address/Document Layout is configured.

opw-6430918

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" />