**Problem:**
Starting the timer on a task that is linked to a sale order item produces a timesheet that is not linked to it, and the Billable toggle is missing from the timer.

**Steps to reproduce:**
1. Install Timesheets and Sales
2. Open a task whose Sales Order Item is set
3. Start the timer from the Timesheets systray
4. Save it and open the resulting timesheet

**Current behavior:**
The Sales Order Item is empty. The Billable toggle only appears after removing and re-adding the task in the timer.

**Expected behavior:**
The timer is billable on the task's sale order item as soon as it is opened.

**Cause of the issue:**
`_get_timesheet_pre_filled_form_data` returns only `project_id` and `task_id`. The timer form merges that pre-fill over `timesheet_default_values`, which `lazy_session_info` computes once per session from `account.analytic.line.new()`
- a record with no project and no task, so `so_line`, `allow_billable` and `has_available_so` are all `False` in it. Because the pre-fill carries none of those keys, they keep the task-independent session values: the timesheet stays unlinked from the sale order item, and the Billable toggle stays hidden since it is displayed from `has_available_so`.

**Fix:**
The pre-fill endpoint is the only place that knows which task the timer is being opened on, so it is where the task-dependent values have to be resolved. Reading them off a new timesheet built with that project and task keeps the endpoint generic - it returns whatever `_get_aw_timesheet_fields_specification` declares, so the sale fields stay owned by sale_timesheet_enterprise rather than being named in timesheet_grid.

Dropping the session defaults instead was rejected: they are also the only source of `date`, `user_id` and `company_id` for the timer record, and removing them makes saving fail on the required Date field.

opw-6423577

Forward-Port-Of: odoo/enterprise#127800

### This is a revision of #119399 which had to be reverted.

Original issue
-----
Deliveries cannot be validated using DPD with Sendcloud, users get an error.

Steps to reproduce
-----
- Set up Sendcloud DPD
- Create a SO
	- Interntional customer
		- Some VAT number
	- Some product
	- Add sendcloud delivery
- Confirm SO
- Validate the linked picking

> Error: “The receiver VAT number is missing; please provide it to continue”

Issue's cause
-----
Tax numbers should be included in the `customs_information` field of the request as per the API

https://sendcloud.dev/api/v2/parcels/create-a-parcel-or-parcels#body-one-of-0-parcel-customs-information-tax-numbers

For the `vat_label` field, we have to force the language to English in the context because the field is translated by default, but sendcloud only accepts the english names (eg French "TVA" is not accepted, expected value is "VAT").

https://github.com/odoo/odoo/blob/d1d1610332a1596d026fb0a42ec236d1a79c71cc/odoo/addons/base/models/res_country.py#L75

Revert cause
-----
The vat_label field is marked for translation (translate=True)

https://github.com/odoo/odoo/blob/d1d1610332a1596d026fb0a42ec236d1a79c71cc/odoo/addons/base/models/res_country.py#L75

So if the user has the DB in french for example, we are sending "TVA" instead of "VAT" in the name field.

Other issues
-----
- We need to provide an actual fallback for `customs_invoice_nr`. As it stands, if we create a new delivery it cannot be validated because Sendcloud doesn't accept for the field to be empty.
- Same for `name`, we need to provide an actual fallback.

-----
Ticket:
opw-6250860

Forward-Port-Of: odoo/enterprise#127425
Forward-Port-Of: odoo/enterprise#124245

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#128071
Forward-Port-Of: odoo/enterprise#126242

The embedding model deprecation cron starts by searching for chunks that are embedded using a model that hasn't been deprecated. However, due to an optimization in the ORM (optimize_type_selection), the search doesn't return any result.

A domain that uses the 'not in' operator is converted by the optimization to use the 'in' operator and the values are replaced by the difference between the available selection values (self._selection) and the values in the domain. So, given that the selection values of the embedding_model field are the non deprecated embedding models and the search domain of the cron is ['embedding_model', 'not in', non deprecated embedding models] , the final domain will be
['embedding_model', 'in', non deprecated models list - non deprecated models list] = ['embedding_model', 'in', []] which will retrieve nothing from the DB because all records have an embedding_model.

The main issue is that the optimization assumes that the available selection values are static. However, an old embedding model can be deprecated and a new one added which makes the optimization fail. So, the selection values are changed to be computed dynamically which will be skipped by the optimization.

On a database that was not created with demo data, registering for Peppol using the "Odoo Demo ID" identification fails instead of activating the local demo/training registration. The registration wizard correctly shows "Demo" as the EDI mode once that identifier is selected, but submitting the registration still reaches out to the real Peppol Access Point, which the wizard cannot connect to, so the registration is blocked.

Steps to reproduce:
-------------------
* Create a new database without demo data (e.g. a regular Odoo Online database, not a /trial one)
* Install Accounting, open the Peppol registration wizard
* Select "Odoo Demo ID" as the Electronic Address Scheme and fill in the other required fields
* Click on Register

> Observation:
The wizard displays "Demo" as the EDI mode, yet registering raises "Failed to connect to Odoo Peppol Proxy." Manually creating the system parameter `account_peppol.edi.mode` with the value "demo" makes the registration succeed, but that parameter is only ever set automatically when the module's demo data is loaded.

Why the fix:
------------
The wizard's displayed `edi_mode` correctly resolves to "demo" for the Odoo Demo ID EAS, but `handle_demo` - which decides whether `_can_connect`/`_create_connection` run against the local mock or the real Peppol proxy - recomputed the mode itself without passing that EAS along, so it could only detect demo mode via the system parameter or an already existing proxy user. Made `handle_demo` pass the record's own `peppol_eas` as `temporary_eas`, aligning its detection with what the wizard already displays.

opw-6448276

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

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