Currently, there is no way to quickly update all quantities within a section or subsection at once.

This change introduces a new quantity field displayed on sections and subsections when hovering over them. When this value is modified, a multiplier is computed (new value / old value) and applied to every line within the corresponding section or subsection.

For example, if the quantity of a subsection is changed from 6 to 3, all quantities of the lines under that subsection are divided by 2.

The same behavior is implemented for the unit column. If the unit of a section or subsection is changed and a conversion factor can be determined between the two units, that factor is applied to all lines within the corresponding section or subsection.

For example, changing from m^2 to cm^2 divide all subline quantities by 10,000.

Furthermore, if a section is configured to hide the composition, we still display the unit and quantity in the PDF and preview. If the user changes the unit or quantity of a section or subsection, we also display them on pdf and preview. We do all these changes on order but not on invoice.

Enterprise PR: https://github.com/odoo/enterprise/pull/127420
Upgrade PR: https://github.com/odoo/upgrade/pull/10417
task-6075605

[IMP] website: enable to translate static page url

The goal of this commit is to add the possibility to translate page url.
Here is an example to illustrate the case: A website page has the url
`/page-en`. If the user adds "French (BE)" as a language on its website,
he can now translate the `page-en` website url into `page-fr`. If the
language of the website and its default language is English, the url of
the page will be `/page-en` but if the language of the website is
French, the url of the page will be `/fr_BE/page-fr`. If the language of
the website is in English and the user is searching for `/page-fr`, the
system detects that the requested page exists but redirects the user to
the English version of the page as the language of the website is in
English. However, if the user is searching for `/fr_BE/page-fr`, it will
be redirected to the French version of the page and the language of the
website will switch to French whatever the original language of the
website was.

When a user translates a url, it is slugified and made unique.
Concerning the website homepage url, if it is a page url, it has to be
the one of the default website language. When a user modifies a page
url, the website homepage url is updated if the modification of the url
is done in the website default language and if the original url was the
default website url.

This commit also modifies the url field of the `website.menu` model: the
`required` and `default` properties are removed; if a menu is linked to
a page, no `url` is needed at record creation. However, the `compute`
method of the field fallbacks on `#` and a `constrains` has been added
on the `url` to ensure it is always set. The field is also not stored:
as the `url` might be the one of the website page that could be
translated, it should be recomputed each time we access it. Because a
menu url could be the one of an external url, another field
`manual_url` is introduced to store it.

task-3355343

-------------------------------------------------------------------------------------------------------------------------------------

[FIX] website: reload web client when installing new language

Steps to reproduce:
- On a website with only 'English' installed, enter in edit mode and add
a new language.
- Go to 'Site' > 'This page' > 'Properties'.
- Hover the 'Page URL' field

-> It is not possible to translate the url.

The problem is that, when a new language is installed, the iframe is
reloaded but not the web client. Due to it, `TranslationButton` has a
wrong version of `localization`.

task-3355343


-------------------------------------------------------------------------------------------------------------------------------------

[IMP] website: correctly display the redirect button at url change

Now that the url can be translated, we only want the redirect button to
appear if the url has been changed in the website default language.

task-3355343

-------------------------------------------------------------------------------------------------------------------------------------

[IMP] website: update cache to avoid extra SQL queries

Since [1], the `all_menus` variable contains website specific menus and
generic menus (not linked to a website). However, the `_update_cache()`
of `child_id` was only applied on website specific menus. The problem is
that due to the previous commits, the `url` field of `website.menu` is
not a stored field anymore and depends on `child_id`. Because
`_compute_visible()` in `website_sale` requires the menu's url, an extra
SQL query was triggered to determine the `child_id` of the generic
menus.

To solve the problem, this commit performs the `_update_cache()` of
`child_id` on all the generic and specific menus at `_compute_menu()` of
a specific website.

[1]: https://github.com/odoo/odoo/commit/aa5bbab0183b1d61d64bd2292cacbff82befeaf1

task-3355343

-------------------------------------------------------------------------------------------------------------------------------------

[IMP] website: only rewrite page url for internal links

Steps to reproduce:
- Create a new page and add it to the website menu.
- Edit the menu item and change its URL to an external one (e.g.
https://www.odoo.com/).
- Save.

-> Clicking on the menu item does not open the external url.

Because the menu is linked to a page, changing the menu url rewrites the
page url. This is not the expected behavior if the new url is external.
Note that this problem became visible thanks to the previous commits
that made menu url not stored. Indeed, before those commits, changing
the menu url still rewrote the page url but as the url was a stored
field of the menu record, clicking on the menu led to the external url.

task-3355343

## Navigable smart-date filters in the search bar

<img align="right" width="382" height="328" alt="image" src="https://github.com/user-attachments/assets/6e527849-0837-412e-aba3-bbddd6bab59c" />


### What
Date filters (`<filter date=.../>`) now offer built-in smart-date options — **Today**, **This Week**, **This Month**, **This Quarter**, **This Year** — and each active one gets **prev/next arrows** to shift the period on the fly from the searchbar facet (eg. `This Week` → last week → next week). 

We keep the existing  month and quarter features, and also add a new **"Custom Date…"** shortcut in each date-filter menu, opening the editor pre-filled with the right field.

<br>

### Why
Filtering by a relative date range was a common need, that devs were hardcoding in views (see commit `[REM] *: remove duplicate relative ranges from filters`). Furthemore, other views (eg. gantt view, custom accounting views...) also had this navigable filter logic (but as an extra section below the search bar). We decided to integrate that feature at the framework level, allowing users to navigate filters faster for example when planning day-by-day or reviewing quarter-by-quarter, while saving vertical space compared to a gantt-style navigator. (we keep the existing gantt view navigator for now as it has a couple more features, it was just an example)

### Also
- Active relative filters keep their menu section **unfolded**, so the selected option stays visible w.
- Period options and smart dates are **mutually exclusive** — picking one clears the other.

### Notes 
- Smart-date facets are **not** click-to-edit like other facets (intentional)

### Technical
- Decided to model the new relative filter type as a top level filter even if its always a children of a date filter. I did this because it makes it easier to add custom behavior with the existing code structure (domain, label, navigation..). The only downside is that it makes it a bit more complex to display. 

task#6260555

Documentation PR: https://github.com/odoo/documentation/pull/18866
Enterprise PR: https://github.com/odoo/enterprise/pull/122986

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

*: hr_payroll, reports, reports_avatax

Purpose: Improve and enhance the US tax report framework
to eventually support future e-filing directly within Odoo.
To do so, the US sales tax report needs to capture all
relevant information, such as exempt sales, taxable sales,
non-taxable sales, and the tax rate. It supports both
Avalara and non-Avalara users.

Configuration: Users can configure taxes specifically
for the US jurisdiction by setting the jurisdiction type,
the following information required by the type (state, county, city).
If the tax is an exempt or nontaxable of a standard tax rate,
then it can be added to the standard tax rate on its exempt and
nontaxable tax field. For Avalara users, the configuration is
automatically handled based on the Avalara response.

The following tax types are supported:
- Fully exempt taxes (ex. 0% exempt tax)
- Fully nontaxable taxes (ex. 0% nontaxable tax)
- Rate-reduction taxes (ex. 6% rate reduced to 4% tax)

Report: The US tax report will organize the taxes based on its
state.
Per state, it lists the taxes in order based on its
jurisdiction type: state, special, county, city. The header
will total the columns based on the base lines to avoid
double-counting.
Per tax row, the column values include its
linked exempt and nontaxable taxes.
- Gross should be a sum of exempt, nontaxable, and taxable values.
- Exempt displays the amount that are exempted.
- Nontaxable displays the amount that are nontaxable.
- Taxable displays the amount that are taxable.
**Note: Rate-reduced taxes will not have its own row and are aggregated
into its parent tax.

task-6223342

PLM ECOs are currently centered around BoM revisions, while product versioning and parent-product impact tracking remain difficult to manage from the ECO flow.

This change improves the ECO workflow around product and BoM revisions by making version updates explicit, exposing where a product is used, and simplifying the ECO form.

This commit's changes:
- Add Product Revision and New Product Introduction ECO types using the standard PLM stages.
- Remove the ECO Apply On/type selection field and rely on the selected product and optional BoM instead.
- Replace the separate Update Version action with an Update Versions wizard opened from Apply Changes.
- Allow the wizard to update the product, revised BoM, parent products, and parent BoMs, with chatter logs on all updated records.
- Apply the ECO from the version wizard.
- Add Used In navigation on ECOs to show parent products that use the ECO product through active BoM hierarchies.
- Add Versions navigation on products to show products linked through BoM revision chains.
- Keep BoM selection optional on ECOs and show "No BoM Change" when no BoM is selected.
- Simplify the ECO form by hiding the ECO type when only one type exists, moving the kanban state into the title area, and simplifying the Revision smart button.
- Remove obsolete PLM document kanban code after the document refactor.
- Adapt PLM workorder integrations after removing the ECO `type` field.
- Extend tests for ECO version updates.

task-6213679

## Navigable smart-date filters in the search bar

<img align="right" width="382" height="328" alt="image" src="https://github.com/user-attachments/assets/6e527849-0837-412e-aba3-bbddd6bab59c" />


### What
Date filters (`<filter date=.../>`) now offer built-in smart-date options — **Today**, **This Week**, **This Month**, **This Quarter**, **This Year** — and each active one gets **prev/next arrows** to shift the period on the fly from the searchbar facet (eg. `This Week` → last week → next week). 

We keep the existing  month and quarter features, and also add a new **"Custom Date…"** shortcut in each date-filter menu, opening the editor pre-filled with the right field.

<br>

### Why
Filtering by a relative date range was a common need, that devs were hardcoding in views (see commit `[REM] *: remove duplicate relative ranges from filters`). Furthemore, other views (eg. gantt view, custom accounting views...) also had this navigable filter logic (but as an extra section below the search bar). We decided to integrate that feature at the framework level, allowing users to navigate filters faster for example when planning day-by-day or reviewing quarter-by-quarter, while saving vertical space compared to a gantt-style navigator.

### Also
- Active relative filters keep their menu section **unfolded**, so the selected option stays visible.
- Period options and smart dates are **mutually exclusive** — picking one clears the other.

### Notes 
- Smart-date facets are **not** click-to-edit like other facets (intentional)

### Technical
- Decided to model the new relative filter type as a top level filter even if its always a children of a date filter. I did this because it makes it easier to add custom behavior with the existing code structure (domain, label, navigation..). The only downside is that it makes it a bit more complex to display. 

task#6260555

Documentation PR: https://github.com/odoo/documentation/pull/18866
Community PR: https://github.com/odoo/enterprise/pull/122986

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

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

Forward-Port-Of: odoo/odoo#281263

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

Forward-Port-Of: odoo/odoo#277790

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

Forward-Port-Of: odoo/odoo#280019

### Expected behavior:
When an e-invoice is created from POS using SInvoice, existing behavior is to directly submit it

### Current behavior:
When a POS order with "Invoice" ticked is confirmed in a VN company, the e-invoice is NOT automatically submitted to SInvoice. Users must manually trigger the send wizard.

### Steps to reproduce:
1. Install l10n_vn_edi_viettel_pos, activate VN company
2. Make an order from POS and check the invoice box
3. Observe SInvoice subsmission error

### Cause of the issue:
- caused by commit https://github.com/odoo/odoo/commit/4f30306ccc9ff82911f90ed8b3714b212e4b77dc, which decoupled invoice PDF generation from POS order validation by setting `generate_pdf=False` in context when `use_download_invoice` is False (default)
- `_generate_pos_order_invoice()` to skip `_generate_and_send()`, which skips VN SInvoice submission.

### Fix:
Override `_generate_pos_order_invoice()` to force generating PDF when auto-send to SInvoice is enabled, restoring `_generate_and_send()` during order validation

opw-6427675

Forward-Port-Of: odoo/odoo#280932

**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#282810
Forward-Port-Of: odoo/odoo#277742

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

Forward-Port-Of: odoo/odoo#281570

### 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#283027
Forward-Port-Of: odoo/odoo#281245

_get_all_addr() feeds the postal address block of generated pain.001
payment files, but does not return the partner's state nor the second
street line. The beneficiary state/province and street complement
(suite, unit, ...) therefore never appear in the generated file, even
when they are set on the partner, and there is no way to fix it from
the record. Some North American banks reject wire transfers whose
beneficiary address lacks the state/province, so those payments fail
regardless of how complete the vendor record is.

Return the state code and street2 alongside the other address
components, from the partner for the base implementation and from the
employee private address for the hr one, so the payment engine can
write them in the PstlAdr block.

Steps to reproduce:
- Install Accounting and enable a generic ISO 20022 payment method on
  a bank journal
- Create a vendor located in the US or Canada with a complete address,
  including the state and a second street line
- Register a vendor payment, add it to a batch and generate the
  pain.001 file
- The creditor PstlAdr has no state/province, and its street line only
  carries the first street field: the street2 part is dropped


Companion enterprise PR emitting the state in the generated file: odoo/enterprise#127958

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

Forward-Port-Of: odoo/odoo#282620
Forward-Port-Of: odoo/odoo#282518

*: point_of_sale,pos_mercado_pago,pos_cashdro,pos_cashmatic,
   pos_safaricom

d7a627160372 renamed the client-side payment interface attached to a pos.payment.method from `payment_terminal` to `payment_interface`, moved integrations off `payment_method_type` onto `payment_provider`, and renamed the `qr_code` type to `bank_qr_code`. Several call sites were left behind and now read attributes or compare against values that no longer exist, so they silently never match.

Mercado Pago calls a method straight off the missing attribute, so an incoming webhook raises a TypeError and the payment line stays pending forever. The rest degrade silently: Cashdro and Cashmatic never cancel on Force Done, Safaricom never resolves the payment promise, and Bank QR lines left in `waiting` are no longer reset to `retry` when the session restarts, leaving them stuck.

Use the existing `useBankQrCode` getter for the type check rather than repeating the literal.

opw-6372208

Forward-Port-Of: odoo/odoo#278977

Steps to produce:
---
- Install `sales` module.
- Go to Settings and enable `Units of Measure and Packaging`.
- Set a long name for `units` UoM.
- Create a Sale Order and add a product via the catalog.

Issue:
---
- Long UoM names are not fully visible in the catalog view.

Root cause:
---
- The outer `<div>` has `d-flex` but lacks `w-100`, causing it to overflow
  its container.

Solution:
---
- Added `w-100` to the outer `<div>` to prevent overflow.
- Adjusted the quantity selector layout for better visibility.

Before:
---
<img width="388" height="141" alt="image" src="https://github.com/user-attachments/assets/dafae08a-3c9d-4163-8894-daa2e4d26f62" />

After:
---
<img width="382" height="154" alt="image" src="https://github.com/user-attachments/assets/abd6f034-be4b-49bf-be9c-c9779de0f30d" />

Enterprise PR: https://github.com/odoo/enterprise/pull/121139

opw-6253382

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

Forward-Port-Of: odoo/odoo#282821
Forward-Port-Of: odoo/odoo#267118

The `iconClass` prop of `ViewButton` was declared optional with no default value, so it resolved to `undefined` whenever a button arch had an `icon` but no `icon_class` attribute — which is the case for the large majority of stat buttons.

The template concatenates that prop into the icon's class string:

`this.icon.class + ... + ' ' + this.props.iconClass`

so `undefined` was stringified and rendered literally, producing `class="o_button_icon oi undefined"` on the icon element.

Give the prop an empty-string default, consistent with `className` in the same props definition. This also covers the components spreading `viewButtonProps` (MultiRecordViewButton, and the Studio button variants in enterprise).

Only form views were affected: list and kanban buttons go through `getButtonInfo` in views/utils.js, which already falls back to `""`.

Introduced by: https://github.com/odoo/odoo/commit/c5a40a608280017ae9ea8f9e9e1c59f778d629ae

task-6485741

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

Currently, an error occurs when user tries to end repair that has a service line and is linked to a sale order or invoice.

Steps to replicate:
- Install `repair` with demo.
- Create a new repair order with a customer and check `Under Warranty`.
- Click on the `Services` page and add a product.
- Click on `Quote` button.
- Return to the repair order through breadcrumbs.
- Click `Confirm Repair` > `Start Repair` > `End Repair`.

Error:
```
  File '/home/odoo/odoo19/community/addons/repair/models/repair_service_line.py', line 120, in _update_repair_sale_order_line
    self.price_unit = 0.0
    ^^^^^^^^^^^^^^^
AttributeError: 'repair.service.line' object has no attribute 'price_unit'
```

Cause:
- The error was introduced after a recent improvement [PR].
- The `repair.service.line` model does not contain a `price_unit` field, which causes the error.
- The `price_unit` field is present in the related Sale Order Line or Invoice Line.
    
Solution:
- The price of the linked Sale Order Line or Invoice Line is now set to zero when the product is under warranty.
    
[PR]: https://github.com/odoo/odoo/pull/260278/files#diff-1ff5f0c96411a07c366ef6410fc4580798593205b57d5740fbb4a56259341c98R102


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

Forward-Port-Of: odoo/odoo#278591

> Replaces 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 its head lost its parent commit, leaving no common ancestor with 18.0. A PR in that state cannot be reopened, so this one continues from a clean branch with the exact same change. The review discussion is in that PR, and the rename asked for there is included here.

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

Forward-Port-Of: odoo/odoo#282956

**Issue**
Printing an invoice for a returned dropshipped tracked product could display the wrong lot/serial number on the invoice report.

**Steps to reproduce**
- Activate "Display Lots & Serial Numbers on Invoices"
- Create a product tracked by serial/lot and enable the dropship route
- Create two lots: "lot1" and "lot2"
- Create and confirm a SO for quantity 2
- Confirm the PO and validate the dropship for both lots
- Create and post an invoice
- Return "lot2" from the dropship picking
- Create and post a credit note for quantity 1
- Click on print on the invoice 
-> The generated PDF displays "lot1 & lot2" instead of "lot1"

**Cause**
While rendering `account.report_invoice_with_payments`, the report calls `_get_invoiced_lot_values` to determine which lot/serial numbers should be displayed:
https://github.com/odoo/odoo/blob/786c373d5ac8afdfb79eb7a7d69c5eb83b919625/addons/sale_stock/models/account_move.py#L31-L32 `invoiced_qties = 2` since the invoice is on a quantity of 2 https://github.com/odoo/odoo/blob/786c373d5ac8afdfb79eb7a7d69c5eb83b919625/addons/sale_stock/models/account_move.py#L44 Three stock move lines are retrieved from the SO:
- the two original dropship deliveries,
- the return move for `lot2`. https://github.com/odoo/odoo/blob/786c373d5ac8afdfb79eb7a7d69c5eb83b919625/addons/sale_stock/models/account_move.py#L63 However, none of them are considered as `is_stock_return` because the dropship locations use `supplier` instead of `internal`: https://github.com/odoo/odoo/blob/786c373d5ac8afdfb79eb7a7d69c5eb83b919625/addons/sale_stock/models/account_move.py#L72-L76 As a consequence:
- The two original delivery move lines each keep quantity `1`: https://github.com/odoo/odoo/blob/786c373d5ac8afdfb79eb7a7d69c5eb83b919625/addons/sale_stock/models/account_move.py#L69 they never pass through the return handling logic (as they should be): https://github.com/odoo/odoo/blob/786c373d5ac8afdfb79eb7a7d69c5eb83b919625/addons/sale_stock/models/account_move.py#L77-L80
- for the last one, `is_stock_return = False` while it should not, thus the quantity is 1 instead of 0. Furthermore, it does not pass by this code:
https://github.com/odoo/odoo/blob/8759429547e42e9f63b15a7c80475be46ef437e2/addons/sale_stock/models/account_move.py#L79 which would make the quantity for lot2 equalled to 0 (1-1) The quantities are therefore accumulated as:
https://github.com/odoo/odoo/blob/786c373d5ac8afdfb79eb7a7d69c5eb83b919625/addons/sale_stock/models/account_move.py#L92

resulting in:
`qties_per_lot = {lot1: 1, lot2: 2}`
instead of:
`qties_per_lot = {lot1: 1, lot2: 0}`

The report selects both lots since it starts with lot1 (qty of 1): https://github.com/odoo/odoo/blob/786c373d5ac8afdfb79eb7a7d69c5eb83b919625/addons/sale_stock/models/account_move.py#L94-L99

opw-6236855

Forward-Port-Of: odoo/odoo#271282
Forward-Port-Of: odoo/odoo#270599

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#278411
Forward-Port-Of: odoo/odoo#276774

### Commit 1: [IMP] l10n_latam_check: improve UX/usability of checks

- The creation of third party checks was not correctly disabled on some list views.
- Align labels of the partner_id to Customer/Vendor depending on the context.
- Display the memo and the initial payment's date on the 3rd party checks
views.

task-5247520

### Commit 2: [FIX] l10n_latam_check: base checks location on a real on_hand field
**Problem 1: On Hand**
Whether a check was still on hand had no field of its own: it was
computed based on the current_journal_id of the check, while
the "On hand" filter approximated it through the payment methods
of the check's current journal.
The two could disagree, and neither could be searched or grouped on.

Expose it as an on_hand computed field, with a compute_sql
counterpart so it stays searchable.
A check is On Hand if its last posted operation was registered on a cash
journal.

**Problem 2: Last operation**
The sorting of the operations of a check was mostly relying on the payment_date
then the write_date and finally the ID. For payments that are registered on the
same day, the computation was often wrong as soon as an older payment was edited
afterwards, which sent the check back to the journal it had already left.
This commit adds a key to the sorting: we now secondly rely on the Journal Entry
ID of the payment, which should always exists for posted payments with a
check, and is created at posting of the payments so it somehow acts as
timestamp of the posting, it also won't re-order if the payments would be
reset to draft and re-posted.

Finally, and even with changes above, we decided that resetting or
cancelling an operation in the middle of the chain of operations
should be prevented. It left the check recorded where it no longer was.
Note that it is still possible to reset the whole chain at once, or
the last operation(s).

task-5247520

**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#282849
Forward-Port-Of: odoo/odoo#277232

* = 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#283315
Forward-Port-Of: odoo/odoo#279085

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

#### Description of the issue/feature this PR addresses:
The "Request Appraisals" server action on hr.employee calls model._create_multi_appraisals(), a method that no longer exists. Running it raises AttributeError: 'hr.employee' object has no attribute '_create_multi_appraisals'.

#### Current behavior before PR:
Commit 8845eb2ac29 replaced the multi-appraisal flow with hr.appraisal.campaign.wizard: it deleted _create_multi_appraisals and repointed the employee list header button to action_open_appraisal_campaign_wizard, but left the action_create_multi_appraisals record in hr_appraisal/views/hr_employee_views.xml. Its code is now the only reference to the deleted method, so the action crashes whenever it is run.

#### Desired behavior after PR is merged:
The dangling action is gone. Requesting appraisals for several employees at once is done with the "Launch Campaign" button already present in the Employees list view; action_open_appraisal_campaign_wizard reads active_ids when active_model is hr.employee and pre-fills the selected employees.

Nothing references the removed xml id, and the record is not noupdate, so _process_end removes it from existing databases on update; no migration script is required. Verified on a 19.0 database: with the orphan record loaded, updating hr_appraisal with this change deletes it.

opw-6408609

Forward-Port-Of: odoo/enterprise#127983
Forward-Port-Of: odoo/enterprise#125630

When the AI agent switched from another view to a pivot view, the pivot view
could crash or open without any active measures.

The AI controller patch applies the agent's adjustments upon receiving the
`APPLY_AI_ADJUST_MODEL` bus event. However, the event could be processed while
the pivot model was still executing `_loadData()`.

In that case, the following sequence occurred:

* `_loadData()` started and awaited.
* The controller patch was executed.
* The patch called `toggleMeasures()`.
* `toggleMeasures()` waited for `_loadData()` to complete.
* `_loadData()` finished and updated the metadata with the available measures.
* `toggleMeasures()` resumed and wrote back the metadata snapshot it had taken
before waiting.

Since `toggleMeasures()` operates on a snapshot of the metadata, the measures
populated by `_loadData()` were lost when the snapshot replaced the current
metadata, leaving the pivot model without its `measures` metadata and causing
the view to crash.

Prevent this race condition by waiting for the pivot model initialization to
complete before applying the AI adjustments.

Also preserve the default active measures when the AI agent does not explicitly
request any measures instead of clearing them and opening an empty pivot view.

task-6384368

Forward-Port-Of: odoo/enterprise#125897

The original issue coudn't be reproduced. But based on what was reported on the ticket, this should improve the behavior of the order receipt.

Steps to reproduce:
-------------------
* Setup the l10n_ke module in 'production' mode
* Make an order in POS and validate it
> Observation: The receipt doesn't contain the SCU information and QR

Why the fix:
------------
Based on the receipt screenshot shared on the ticket (from Odoo 19.3) we can see that some informations are shown on the ticket. The information shown are the one received from the etims api, it means the call went through and the response was received.

As the qrCode URL only needs `l10n_ke_oscu_signature` to be generated, we can assume that if this field is set we can safely generate the URL and generate the QR code.

https://github.com/odoo/enterprise/blob/ee7e6894ed313db844aeff5ba5e19de3ad94898e/l10n_ke_edi_oscu_pos/models/pos_order.py#L252-L256

Based on this assumption we can change the condition to return the URL or not based on the presence of `l10n_ke_oscu_signature` instead of the state of the order being `sent`.

In 19.0, the receipt is showing no info at all (when 19.3 is showing some info like the signature). This is also happening because the URL was falsy. And when that is the case we do not show any SCU information

https://github.com/odoo/enterprise/blob/ee7e6894ed313db844aeff5ba5e19de3ad94898e/l10n_ke_edi_oscu_pos/static/src/overrides/components/order_receipt/order_receipt.xml#L56

opw-6352120

Forward-Port-Of: odoo/enterprise#127045

### Problem
- The fictitious remuneration used for departure holiday attest and December double holiday regularization
  was computed using the salary applicable at the end of the previous year for all assimilated absence periods.

**For an employee with:**

- 20 days of assimilated absence in February with a salary of 2,000.
- A salary increase to 3,000 in June.
- Another 20 days of assimilated absence in November.

```
The previous computation was:
(40 × 3,000) × (3 / 13 / 5)
```
- where all assimilated absence days were valued using the wage
  applicable on the last day of the previous year.

- Instead, the remuneration should be computed using the wage applicable

```
during each assimilated absence period:
((20 × 2,000) + (20 × 3,000)) × (3 / 13 / 5)
```
- Compute the fictitious remuneration using the contract wage applicable
to each payslip period so that each assimilated absence is valued with
the correct monthly salary before applying the holiday formula.

task-5932817

Forward-Port-Of: odoo/enterprise#122848

## Previous Behavior Before this PR:
Users could have their always-active event split by an AFK event inside of Timesheet Assistant. AFK event durations were also inaccurate, and the Google Meet description was incorrect.

## Steps to Reproduce:
1. Generate an always-active event (e.g., join a meeting in Google Meet).
2. Generate non-key events (e.g., visit a website without an ActivityWatch rule).
3. Go AFK.
4. Generate a new non-key event.
5. The Timesheet Assistant will show three suggestions in the following order: an always-active suggestion, an AFK suggestion, and another always-active suggestion for the same activity.

## New Expected Behavior After this PR:
The Timesheet Assistant now blocks the creation of AFK suggestions when the previous key event is marked as always-active. AFK event durations have been updated to ensure their values are accurate. The Google Meet description has also been corrected.

task-[6431526](https://www.odoo.com/odoo/project/4105/tasks/6431526)

Forward-Port-Of: odoo/enterprise#127299
Forward-Port-Of: odoo/enterprise#127028

1- The benefit fields related to the hr.version have a domain that limits them to the whitelisted fields used to copy values from a template, which does not always include benefit fields. The advantage of the whitelist is that it factored in for the allowed countries, so instead of duplicating this logic to benefit fields and implementing it in every l10n, we can check which module the field comes from.

example:
The field [`company_car_total_depreciated_cost`](https://github.com/odoo/enterprise/blob/ce691cd6aaacfb86cd866698d2fcc3fe930912cb/l10n_be_hr_payroll_fleet/models/hr_version.py#L62) cannot be selected as `res_field_id` when it should be possible as we see in the [data](https://github.com/odoo/enterprise/blob/ce691cd6aaacfb86cd866698d2fcc3fe930912cb/l10n_be_hr_contract_salary/data/hr_contract_salary_benefit_data.xml#L6), it is not whitelisted because we dont want to copy its value from a template.

2- Another fix is the inverse of the public field, there's a traceback because the selection field is always converted to a string and cannot be used to browse as is.
```py
  File "/data/build/enterprise/hr_contract_salary/models/hr_contract_salary_benefit.py", line 238, in _inverse_res_field_public
    record.res_field_id = self.sudo().env['ir.model.fields'].browse(record.res_field_public)
    ^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/odoo/orm/fields.py", line 1890, in __set__
    write_value = self.convert_to_write(value, records)
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/odoo/orm/fields_relational.py", line 387, in convert_to_write
    return value.id
           ^^^^^^^^
  File "/data/build/odoo/odoo/orm/fields_misc.py", line 115, in __get__
    raise ValueError("Expected singleton: %s" % record) from None
ValueError: Expected singleton: ir.model.fields('1', '7', '3', '8', '4')
```

Forward-Port-Of: odoo/enterprise#128275
Forward-Port-Of: odoo/enterprise#127743

The PstlAdr block written into pain.001 files never contains the
partner's state/province nor the second street line, even when they
are set on the record: _get_all_addr() now returns them, but
_get_PstlAdr() also needs to write them out. Some North American banks
reject wire transfers whose beneficiary address lacks the
state/province, so those payments fail regardless of how complete the
vendor record is.

Emit CtrySubDvsn when the address has a state, before Ctry as required
by the element order of the PostalAddress schema, and append street2
to the street address line.

Steps to reproduce:
- Install Accounting and enable a generic ISO 20022 payment method on
  a bank journal
- Create a vendor located in the US or Canada with a complete address,
  including the state and a second street line
- Register a vendor payment, add it to a batch and generate the
  pain.001 file
- The creditor PstlAdr has no state/province, and its street line only
  carries the first street field: the street2 part is dropped


Requires odoo/odoo#282518, which makes _get_all_addr() return the state and street2.

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

Forward-Port-Of: odoo/enterprise#128021
Forward-Port-Of: odoo/enterprise#127958

Issue:
Swiss payslips count one extra absence day for employees without a working schedule. A one day accident leave can therefore be prorated as two days, reducing the regular wage and overstating the accident salary.

Steps to reproduce:
* Install Swiss Payroll.
* Configure a monthly employee without a working schedule.
* Assign one day of accident time off.
* Generate the payslip for that month.

Cause:
The Swiss wage computation derives absence boundaries from the date portion of the leave's UTC datetimes: https://github.com/odoo/enterprise/blob/16c29e1bab34b5bcb2b001477d928ec5eb294a97/l10n_ch_hr_payroll/models/hr_payslip.py#L313-L330

A fully flexible employee's full day leave starts at local midnight. In timezones ahead of UTC, that start is stored on the previous UTC date, so the inclusive calendar day computation adds an extra day.

Solution:
We need to use the requested time off dates for both payslip range filtering and absence proration. These fields preserve the calendar days selected by the user independently of timezone conversion, while leaving the UTC datetimes and half-day handling unchanged.

opw-6435086

Forward-Port-Of: odoo/enterprise#127849
Forward-Port-Of: odoo/enterprise#127513

Steps to produce:
---
- Install sale_tiktok module.
- Create two active tiktok.shop records.
- Run the database neutralization command.

Issue:
---
- Neutralization fails with a PostgreSQL error:
 ```py
 duplicate key value violates unique constraint tiktok_shop_unique_active_shop`
 DETAIL: Key (tiktok_shop_ref)=(1) already exists.
```

Root cause:
---
- At [1], we are setting `tiktok_shop_ref = 1` for all `tiktok_shop` records. Because `tiktok_shop` enforces a partial unique constraint on `tiktok_shop_ref` for active shops [2], setting the same reference value `1` on multiple active shops violates this constraint.

Solution:
---
- Update sql to assign a row-unique string to each shop. This strips the real shop reference while maintaining uniqueness across active shop records so neutralization completes cleanly.

[1]https://github.com/odoo/enterprise/blob/85754b0354b76da8b4d87a3a81dd19679ed35d15/sale_tiktok/data/neutralize.sql#L1-L8

[2]https://github.com/odoo/enterprise/blob/85754b0354b76da8b4d87a3a81dd19679ed35d15/sale_tiktok/models/tiktok_shop.py#L136-L139

opw-6451715
---

Forward-Port-Of: odoo/enterprise#127532

Currently, an error occurs when a user adds a rental product to the cart, opens the corresponding sales order, removes the rental period, and then opens the cart again.

Steps to replicate:
- Install `website_sale_renting` with demo.
- Open website > shop > add the product named `Projector`.
- Click Ecommerce in the menu bar > Orders .
- Remove the `Confirmed` filter > Click on the top order (should be containing the projector product.)
- Remove the `Rental Period` and go to the cart.

Error:
```
QWebError: Error while rendering the template:
AttributeError: 'bool' object has no attribute 'time'
Template: website_sale.shorter_cart_summary
```

Cause:
- When the user removes the rental period (`rental_start_date` and `rental_end_date`), both fields are set to `False`. When the cart is opened again, these values trigger the error in [line].

- Since the rental period has been removed from the order, the order is converted to a regular Sales Order (see [PR] and its [task]). Therefore, the Rental Period should no longer be displayed.

Solution:
- Use `is_rental_order` to determine whether to render the rental period instead of `has_rentable_lines`, since `has_rentable_lines `only checks whether the product is rentable [1], which is determined by the product's `rental_periodicity` [2].

- `is_rental_order` is a better check here because it indicates whether the rental period is actually defined on the order [3].

[line]: https://github.com/odoo/enterprise/blob/7c80c9ffa9e7812267f2ac285e3a3fc5ca501814/website_sale_renting/views/templates.xml#L207

[task]: https://www.odoo.com/odoo/all-tasks/6003684

[PR]: https://github.com/odoo/enterprise/pull/106381/commits/56ec41d81f7536f047a1586a12ea6f6e8414b844

[1]: https://github.com/odoo/enterprise/blob/f23ef9c604d8ce6be152d5e5bf6f72bd68b31451/sale_renting/models/sale_order.py#L140-L143

[2]: https://github.com/odoo/enterprise/blob/f23ef9c604d8ce6be152d5e5bf6f72bd68b31451/sale_renting/models/sale_order_line.py#L61-L64

[3]: https://github.com/odoo/enterprise/blob/f23ef9c604d8ce6be152d5e5bf6f72bd68b31451/sale_renting/models/sale_order.py#L135-L138

sentry-7663524549

Forward-Port-Of: odoo/enterprise#128084

Discarding the "Update Company Car" confirmation froze the whole backend: no button reacted anymore and only a page refresh recovered it.

Steps to reproduce:
- Validate a payslip for a Belgian employee
- Create a DMFA covering that quarter and mark it as done
- Change the company car of that employee and save
- Click Discard (or the cross) on the confirmation dialog

onWillSaveRecord is called from within Record._save, which itself runs inside the model mutex. Awaiting record.discard() from there queued the discard behind the very save that was waiting for it, so neither promise ever settled. Since the save was dispatched through executeButtonCallback, every button of the view and of the overlay container stayed disabled, and the mutex stayed blocked for the rest of the page life, making any later save or discard hang as well.

Fire the discard without awaiting it, the way account's currency form controller already does: the hook returns false, the save releases the mutex, and the queued discard then reverts the record.

task-6463069

* = din5008_account_followup, din5008_industry_fsm

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

**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`).

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

opw-6392649

Forward-Port-Of: odoo/enterprise#128453
Forward-Port-Of: odoo/enterprise#126006

Split out of #282959, which is now the ~10 purely mechanical `useLayoutEffect` → `useOnChange` sites. `useNavigation` is the one that is not mechanical, so it gets its own PR. The two touch no files in common.

### Why this one is different

Everywhere else in the migration the dependency list is nothing but refs, which makes the swap timing-neutral: a ref signal is written during the DOM patch, so the effect's microtask fires straight after it with the patched DOM already in place, where the shim's `onPatched` ran it.

`useNavigation` is the only hook in the series that hands state back to the caller for a lifecycle hook to read:

```
time (down)           useLayoutEffect         useOnChange
--------------------  ----------------------  --------------------
patch DOM             -                       effect queued
onMounted (hook)      update() -> items       not registered
onMounted (consumer)  reads items[0]: ok      reads items[0]: []
microtask             -                       update() -> items
```

`onMounted` never runs again, so the missed `setActive()` is lost rather than merely delayed. This is what broke the 7 `navigation_hook` tests on the first attempt.

### What this does instead

The first version of this fixed the ordering by calling `navigator.update()` from an extra `onMounted` inside the hook. @seb-odoo's review comment on #282959 was that the actual problem is that `Navigator` is not reactive, and that is right: `items` was a plain field reassigned by `update()`, sitting outside the reactive graph, so *something* had to push a refresh in at the right moment.

So `items` is derived instead, and the ordering question disappears rather than being answered:

- `_elements` — a computed over `options.getItems()`, memoised on a shallow comparison. Every signal that callback reads (the container ref, an `isOpen()` state) is tracked, so the list re-derives on its own.
- `_items` — a computed over it that reconciles `NavigationItem`s, reusing the instance of an element that is still there so its listeners survive.
- `items` — a getter over that. Reading it from anywhere, including a consumer's own `onMounted`, derives against the DOM as it is at that moment.
- `update()` — now just an invalidation, for the DOM, which is the one input that cannot notify us. It still syncs eagerly, so `update(); this.items` keeps working for `dropdown.js`.
- `_syncActiveItem()` — the active-item reconciliation, `onUpdated` and `shouldFocusFirstItem` move out of the derivation, because they move focus and a plain read of `items` must not do that. Idempotent per derivation, which is what the hand-rolled `didUpdate` flag bought.

### Blast radius

`navigation.js` only, plus one test. No consumer changes: `items`, `update()` and `onUpdated` keep their signatures, and enterprise never constructs a `Navigator` nor calls `update()`.

Nothing reads `items` during a render — every read across both repos is a hotkey callback or an event handler. That matters now that `NavigationItem` construction, which attaches listeners and writes `ariaSelected`, happens inside a computed. It is a constraint the code satisfies today rather than one it enforces.

The destroy test stepped on `update()`, which no longer runs on mount at all, so it steps on `_syncActiveItem` instead.

### For review

- `onUpdated` and `shouldFocusFirstItem` now fire from an effect (a microtask after patch) for signal-driven changes, where `useLayoutEffect` fired them inside `onPatched`. Explicit `update()` callers are unaffected. This is the same class of timing shift that broke the tests the first time, so it is the thing to look at hardest.
- `activeItem` / `activeItemIndex` are still plain fields. Making those reactive is the other half of "properly reactive" and is deliberately not in here.

Draft until CI has had a go at it.

pos*: point_of_sale, pos_loyalty, pos_hr, pos_online_payment, pos_stock,
l10n_in_pos, l10n_id_pos

Refactor the customer display communication to make it more efficient,
decouple the terminal and display sides, and avoid unnecessary requests
when no display is connected.

- Replace the effect on `pos_service` with targeted listeners on order-related events.
- Split `customerDisplayService` into two OWL plugins: `CustomerDisplayTerminalPlugin` for the PoS terminal and `CustomerDisplayPlugin` for the customer display.
- Centralize payload generation through `GeneratePrinterData` and remove the deprecated `CustomerDisplayPosAdapter`.
- Replace `device_uuid` with a `device_identifier` generated by `DeviceIdentifierSequence`.
- Use a registration route to track connected customer displays: displays announce themselves with `ADD` and `REMOVE`, while terminals use `PING` to discover displays after startup or reload.
- Skip payload generation and requests when no customer display is connected.
- Refactor customer display tests to exercise the real application flow and assert against system-generated payloads.

```mermaid
flowchart LR
    POS([PosStore])
    UI([Customer display UI])

    subgraph Terminal["CustomerDisplayTerminalPlugin — app/plugins"]
        direction TB
        initT["init({ identifier, models, scale, bus, ... })"]
        sendOrder["sendOrder(order)"]
        build["_buildDisplayPayload()"]
        send["send(payload)"]

        sendOrder --> build --> send
    end

    subgraph DisplaySide["CustomerDisplayPlugin — customer_display"]
        direction TB
        initD["init({ bus })"]
        onData["_onDataReceived()"]
        data[("data — signal")]

        onData --> data
    end

    POS -->|initCustomerDisplay| initT
    POS -->|order or screen changed| sendOrder
    UI -->|mounted| initD

    send -->|"update_customer_display — bus"| onData
    send -.->|"BroadcastChannel — only if the request fails"| onData
    data -->|render| UI
```

Task-5911881