**Steps to reproduce**
- Go to Hong Kong company
- Go to payroll
- Go back and refresh your browser
- Go to payroll

**Crash:**
OwlError: Got duplicate key in t-foreach: pending_175_2026-08-31
    Error: Got duplicate key in t-foreach: pending_175_2026-08-31
        at PayrollDashboardComponent.template_hr_payroll_Dashboard (eval at compile (https://123484110-master-all.runbot135.odoo.com/web/assets/debug/web.assets_web.js:16100:14), <anonymous>:59:49) (/web/static/lib/owl/owl.js:7070)
        at RootFiber.render (https://123484110-master-all.runbot135.odoo.com/web/assets/debug/web.assets_web.js:12537:28) (/web/static/lib/owl/owl.js:3507)
        at ComponentNode.render (https://123484110-master-all.runbot135.odoo.com/web/assets/debug/web.assets_web.js:12795:15) (/web/static/lib/owl/owl.js:3765)

**Reason:**
04065101644 introduced caching on payroll dashboard. Cached pending warnings were keyed by id + date only, dropping the schedule that distinguishes cards for the same warning across pay schedules (e.g. monthly vs weekly).
Colliding keys crashed the dashboard with a duplicate t-foreach key, notably on l10n_hk which mixes both schedules.

task-6522399

### Prevent the play icon from flipping in RTL
Prior to this PR, the play icon was being flipped in RTL, which caused confusion.
This PR ensures that the icon is displayed consistently in both RTL and LTR layouts.

### Make disabled button values optional
Prior to this PR, disabled values were mandatory when overriding button variables.
This could cause color issues when those variables were not explicitly defined.
This PR makes the disabled values optional and falls back to the default values when they are not defined.

task-6501706

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

---

| Before | After |
|--------|--------|
| <img width="187" height="122" alt="Screenshot 2026-08-26 at 15 49 05" src="https://github.com/user-attachments/assets/006830b7-4bd1-43f0-8fc0-f35e9ec66fe5" /> | <img width="212" height="148" alt="image" src="https://github.com/user-attachments/assets/a2c59ec2-e1ce-4a3f-bdc5-37a9fe628126" /> |
| <img width="798" height="310" alt="image" src="https://github.com/user-attachments/assets/f0440f18-f1fa-4b46-b43a-e13d816beb26" /> | <img width="806" height="270" alt="image" src="https://github.com/user-attachments/assets/fdcb1364-353f-416c-a297-fb1bcdd316ce" /> |









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

Before this commit:
- With the new tax return UI, the tax return deadline date pill has low contrast
  between the pill's background color & text color, and it became hard to see
  the actual date shown in the pill.
- Behaviour before:
<img width="385" height="70" alt="image" src="https://github.com/user-attachments/assets/382d2961-0bd9-4552-a7dd-175b6cfa49e7" />
<img width="344" height="73" alt="image" src="https://github.com/user-attachments/assets/6301929b-0cec-4411-b8e1-4a4a65bc9f9e" />

---
After this commit:
- Changed the Bootstrap class for the deadline date pill for the secondary case.
  Now we are explicitly defining the text color for enhanced contrast with the
  background color.
- Behaviour after:
<img width="308" height="73" alt="image" src="https://github.com/user-attachments/assets/50499178-8bba-4917-abd5-026ea287df3e" />
<img width="302" height="74" alt="image" src="https://github.com/user-attachments/assets/59537317-2b7c-4ab5-8828-56f8197ff16f" />

---
Task-6523848

*: account_accountant, stock_barcode

### Adapt attachment preview
This PR adapts the border of the attachment preview to match the new Frost design.

### Adapt o_switcher colors
This PR adapts the o_switcher component to:
- Ensure consistent border colors
- Adjust the color of disabled buttons

### Adapt `o_kanban_tip_filter`
This PR reviews the spacing and button styles of `o_kanban_tip_filter` to align with the new Frost design.

task-6501706

Requires:
- https://github.com/odoo/odoo/pull/284724

---

| Before | After |
|--------|--------|
| <img width="1920" height="929" alt="image" src="https://github.com/user-attachments/assets/b424769f-77f3-4a2f-a0fe-f78bf757ab33" /> | <img width="1919" height="816" alt="image" src="https://github.com/user-attachments/assets/60e5776a-a846-4fb7-b0f3-b83b7ec00cfd" /> |
| <img width="508" height="426" alt="image" src="https://github.com/user-attachments/assets/b53c88c2-5f03-4895-9842-86372396a8e3" /> | <img width="578" height="208" alt="image" src="https://github.com/user-attachments/assets/129fd800-8e99-4355-b283-6f0cad07b574" /> |
| <img width="1920" height="1094" alt="image" src="https://github.com/user-attachments/assets/e01b401b-dc1c-4569-920c-03e182776aca" /> | <img width="1920" height="474" alt="image" src="https://github.com/user-attachments/assets/83b0f76c-b0bd-478b-9f55-6019eb8f5acf" /> |

**Steps to reproduce:**
- Install l10n_din5008 and Accounting.
- Enable Snailmail from Accounting → Settings.
- Create a German customer (Fiscal Country: Germany).
- Create and post a customer invoice using the DIN5008 report layout.
- Select Send by Post.
- Enable Developer Mode and navigate to Settings → Technical → Email → Snailmail Letters.
- Open the generated letter and send it.

**Observed behavior:**
The address blocks are incorrectly aligned when the DIN5008 report is rendered for snailmail. The information block and recipient address do not follow the expected vertical positioning.

**Cause:**
The DIN5008 layout previously applied vertical alignment rules to its table cells. These rules were removed while adapting the layout to the invoice table structure and its customizations, such as the position column and line numbering.

While this alignment is no longer required for the regular DIN5008 invoice layout, the snailmail layout relies on it to correctly position the sender/invoice information and recipient address blocks.

**Fix:**
Add a `snailmail` class to the DIN5008 invoice section when `snailmail_layout` is present in the rendering context.

Restore the required vertical alignment rules scoped to this class so they only affect snailmail reports, without changing the regular DIN5008 layout.

**References**

* **PR:** [#201225 – DIN5008 layout improvements](https://github.com/odoo/odoo/pull/201225)
* **Ticket:** [6387869](https://www.odoo.com/odoo/project/49/tasks/6387869)

opw-6387869

Forward-Port-Of: odoo/odoo#286056
Forward-Port-Of: odoo/odoo#285891

Steps to reproduce the bug:
- Warehouse configured for 2-Step Manufacturing
- Component "C1":
    - Routes: MTO + Buy
    - Tracking: By Unique Serial Number
    
- Create a Finished product:
    - Route: Manufacture
    - Tracking: By Unique Serial Number
    - BoM:
        - component "C1": 1 unit
- Create and confirm the Manufacturing Order
- Generate/assign the serial number for the finished product immediately, before the related purchase order is even confirmed
- Confirm the Purchase Order
- Receive the component
- Transfer the component to WH/Pre-Production
- Click Produce All

Problem:
A Consumption Warning was displayed stating that the consumed quantity differs from the expected quantity, even though the consumed quantity was exactly equal to the BoM quantity and no manual quantity change was performed. Clicking "Set Quantities & Validate" completed the MO successfully, hiding the inconsistency.

`_get_consumption_issues()` only counts a raw move's quantity as "consumed" when `move.picked` is `True`
[(odoo/addons/mrp/models/mrp_production.py#L1791)](https://github.com/odoo/odoo/blob/19.0/addons/mrp/models/mrp_production.py#L1791).
Generating the finished product's serial number calls `_set_qty_producing()` 
[(odoo/addons/mrp/models/mrp_production.py#L1402)](https://github.com/odoo/odoo/blob/19.0/addons/mrp/models/mrp_production.py#L1402).
, which itself only sets `move.picked = True` when `move.quantity` is truthy 
[(odoo/addons/mrp/models/mrp_production.py#L1443)](https://github.com/odoo/odoo/blob/19.0/addons/mrp/models/mrp_production.py#L1443).

At that point the MTO component had not been received yet, so `move.quantity` was still 0 and `picked` was never set. Once the component was later received and transferred to Pre-Production, `_action_assign()` correctly reserved the raw move (`quantity` became correct), but nothing ever went back to flip `picked` to `True`, since `_set_quantities()` 
[(odoo/addons/mrp/models/mrp_production.py#L2932)](https://github.com/odoo/odoo/blob/19.0/addons/mrp/models/mrp_production.py#L2932).

only calls `_set_qty_producing()` again when `qty_producing` is still falsy, which was no longer the case. `_get_consumption_issues()` therefore still counted the consumed quantity as 0 against the expected BoM quantity.

Solution:
In `pre_button_mark_done()`, for auto productions (single unit being produced), after `_set_quantities()` runs, also mark as `picked` any non-manual-consumption raw move that is not yet `picked` but whose reserved `quantity` already exactly matches its own `product_uom_qty`. This is scoped to auto productions only, since on a multi-unit production a raw move's aggregate `quantity` can equal its `product_uom_qty` by coincidence (reservation for future backorder steps) even though only part of it is meant to be consumed for the current step.

opw-6421531

Forward-Port-Of: odoo/odoo#285405
Forward-Port-Of: odoo/odoo#281258

Issue
-----------
Long delivery method names containing lists of locations/zones do not wrap properly on the eCommerce checkout page, causing the layout to overflow.

Cause of the issue
-----------
The first column of `[.o_delivery_method_row](https://github.com/odoo/odoo/blob/saas-19.3/addons/website_sale/static/src/scss/website_sale_delivery.scss#L2)` uses `minmax(max-content, 1fr)`. `max-content` prevents the column from shrinking when the delivery method name is too long.

Steps to reproduce
-----------
1. Create a Delivery Method with a long list of locations/zones in its name.
2. Go to the eCommerce checkout at the address page.
3. Observe that the delivery method name does not wrap and breaks the layout.

Before Fix
-----------
The `max-content` minimum prevents the delivery method name from wrapping, causing the layout to overflow.

<img width="1781" height="852" alt="image" src="https://github.com/user-attachments/assets/1150a8ef-e2d8-49ab-9553-fe9728258060" />



After Fix
-----------
Change `max-content` to `min-content` so the column can shrink and the delivery method name wraps.

<img width="1882" height="890" alt="image" src="https://github.com/user-attachments/assets/84cfd5a4-796d-4b9f-bfdb-c18434f8b67f" />



[OPW- 6486780 ](https://www.odoo.com/odoo/project/70/tasks/6486780)
[UPG- 4609267 ](https://upgrade.odoo.com/odoo/upgrade.request/4609267)


Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#284714

Steps to reproduce:
- Install `l10n_fr_pdp` and `l10n_be` module
- Activate `French e-invoicing` (you need to put your DB in test mode)
  (i.e: `account_peppol.edi.mode = 'test'` in system parameter) Refer this Documentation https://www.odoo.com/documentation/19.0/applications/finance/fiscal_localizations/france.html?highlight=e%20invoicing#localizations-france-e-invoicing-fac-elec-config
- Create a Invoice and Sent with `E-invoicing`
- Run `PEPPOL: retrieve new documents` Cron
- In Invoice Other Info >  `E-Invoicing Status` should be in `Done` state
- Now Vendor Bill is created for that invoice > Cancel that bill with reason >  Check `E-Invoicing Status` response for bill(one response will be without UUID)
- Go to schedule actions > `PEPPOL: update message status`
- Run it and get the traceback: `KeyError: 'false'`

Issue:
When sending a lifecycle response to the French PDP, `_pdp_send_response` calls the `/api/pdp/1/send_response` endpoint and expects IAP to return a `message_uuid` for each response.

However, IAP return a response without a message UUID, for example: ` {'messages': [{'message_uuid': False}]}` `_pdp_send_response` currently assumes that every returned message has a valid UUID and creates an `account.peppol.response` with:
```
    'peppol_message_uuid': False
    'peppol_state': 'processing'
```
This leaves an `account.peppol.response` in `processing` state without a UUID that can be used to track it.

During the next execution of `_cron_peppol_get_message_status`, `_peppol_get_message_status` retrieves this response through `_peppol_get_documents_for_status` and builds `uuid_to_record` using `peppol_message_uuid` as the key. The resulting mapping contains the Python value `False` as a key.

The cron then calls the PDP `1/get_document` endpoint with this invalid UUID. IAP returns it as the string `'false'`, which is passed to `_peppol_process_messages_status`. The French PDP implementation tries to retrieve the corresponding record with: `uuid_to_record[uid]`

Since the mapping contains `False` while `uid` is `'false'`, this raises: `KeyError: 'false'`

This failure prevents the status cron from completing the processing of the messages.

Solution:
Avoid creating the `account.peppol.response` when IAP does not return a `message_uuid`. A response without a UUID cannot be tracked through the PDP status flow, so creating it in `processing` state only leaves an
invalid record that will later cause the status processing to fail.

opw-6453133

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

Forward-Port-Of: odoo/odoo#286147
Forward-Port-Of: odoo/odoo#281691

## Steps to Reproduce:
- Install `l10n_tr_nilvera_edispatch` module.
- Run "**Nilvera: retrieve e-Dispatch purchase PDFs**" Scheduled Action.

## Error:
```
ValueError: Binary field stored in attachment, accepts only existence check; skipping domain in condition ('l10n_tr_nilvera_edispatch_xml_file', 'in', OrderedSet([True]))
```

## Cause:
After commit https://github.com/odoo/odoo/commit/3641f23a9b4cd401444ca3371873d8123922f7b1, The condition operators `=` and `!=` are normalized to `in` and `not in` respectively.

As a result:
```
('field', '=', True) becomes ('field', 'in', OrderedSet([True])) and 
('field', '=', False) becomes ('field', 'in', OrderedSet([False]))
```

After this normalization, the domain optimizer `_optimize_type_binary_attachment()` is applied - [1]. 
For attachment-type binary fields, it only allows `in/not in` operators, and a value should be `{False}`. 
Therefore, the condition (converted) `('l10n_tr_nilvera_edispatch_xml_file', 'in', [True])` is rejected.

Binary fields with `attachment=True` are not stored as a boolean value. When converting their domain to SQL, `condition_to_sql()` - [2] handles them as an EXISTS check on `ir.attachment` to determine whether an attachment exists.

## Fix:
This commit replaces the `= True` in the condition with `!= False`.

[1] - https://github.com/odoo/odoo/blob/762fd7c0b65e8f8e3eb59eb8a57b1394cb176339/odoo/orm/domains.py#L1782-L1784
[2] - https://github.com/odoo/odoo/blob/762fd7c0b65e8f8e3eb59eb8a57b1394cb176339/odoo/orm/fields_binary.py#L217-L218

sentry-7627832395

Forward-Port-Of: odoo/odoo#284401

**Current behavior before PR:**

Steps to reproduce the issue:

- Create a link via typing a valid URL + space.
- Copy/Paste a different URL from the browser.
- Select the entire link you just created.
- Paste the copied URL on top of it.

Notice that the label is still the old URL even
though the URL actually changed. This happens because after commit [1] When pasting a URL over an active text selection, selected content is converted into a link pointing to the pasted URL. This should not be the case if selected content is a link with same label and URL.

**Desired behavior after PR is merged:**

If a link is entirely selected and its label is the same as URL then it should replace the existing link label with new URL.

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

task-6456004





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

Forward-Port-Of: odoo/odoo#286081
Forward-Port-Of: odoo/odoo#281700

Version:
--------
- 19.0+

Steps to reproduce:
-------------------
- Install `stock`, `purchase`, and `accountant`
- Create a storable product with:
  - Tracking Inventory enabled
  - Control Policy set to **Ordered Quantities**
- Create and confirm a Purchase Order with some unit price
- Do not receive or invoice the order
- From the Purchase Order gear menu, click **Accrued Expense Entry**

Issue:
------
The Accrued Expense Entry wizard opens, but no accounting lines are
generated.

For products invoiced on **Ordered Quantities**, the ordered quantity
should already be accrued even though nothing has been received.

Cause:
------
This issue was introduced after this changes [commit](https://github.com/odoo-dev/odoo/commit/81f25bc57b8433a65bf33950c64dc7582240a229)

Previously, the accrual wizard relied on the stored
`qty_to_invoice` field, whose computation already respected the
product's Control Policy.

For products invoiced on **Ordered Quantities**,
`_compute_qty_invoiced()` computes the quantity to invoice from the
ordered quantity:

https://github.com/odoo/odoo/blob/810a02a577c2811dc5c12f0abf45eebb9cf96d00/addons/purchase/models/purchase_order_line.py#L147-L152

The refactoring replaced this logic with the new
`amount_to_invoice_at_date` field, which always computes the invoicable
quantity as:

`qty_received_at_date - qty_invoiced_at_date`
https://github.com/odoo/odoo/blob/65dbcabcd243abf24d6d3c3788d2caff66485790/addons/purchase/models/purchase_order_line.py#L282-L285

This formula ignores the product's Control Policy.

For products invoiced on Ordered Quantities, before any receipt:

`qty_received_at_date` = 0
`qty_invoiced_at_date` = 0

therefore:

`amount_to_invoice_at_date` = 0

The Accrued Expense wizard filters out lines whose
`amount_to_invoice_at_date` is zero:

https://github.com/odoo/odoo/blob/65dbcabcd243abf24d6d3c3788d2caff66485790/addons/account/wizard/accrued_orders.py#L168-L178

As a result, the purchase order line is excluded entirely and the
wizard produces no accounting entries.

The same assumption is also used later in
`account.accrued.orders.wizard._compute_move_vals()` when computing
tax-included amounts, causing incorrect accrual values for
Ordered Quantities products whenever receipts and invoices differ.

Fix:
----
Introduce `_get_qty_to_invoice_at_date()`, mirroring the existing
purchase_method logic used by _compute_qty_invoiced().

The helper returns:

product_qty - qty_invoiced_at_date for Ordered Quantities
products;
`qty_received_at_date` - `qty_invoiced_at_date` for
Received Quantities products.

Now products invoiced on `Ordered Quantities` become
accruable as soon as the Purchase Order is confirmed;

---

opw-6290782

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

Forward-Port-Of: odoo/odoo#284507
Forward-Port-Of: odoo/odoo#276435

Step to reproduce
- install l10n_pe_edi_pos with demo and switch to PE company
- from settings> "Signature Provider" set it to SUNAT
- create a pos, enable "Basic Receipt" from settings
- open pos and fulfill a order
- from feedback screen, print > print basic recipt

Observation:
- `Amount In Word` is visible in basic receipt, we should not show such info in
basic receipt

Cause:
- commit [1] introduces the template `l10n_pe_edi_pos.pos_order_receipt`,
which adds the info block to the receipt using xpath
  `<xpath expr="//div[contains(@t-if, 'use_self_invoicing')]" position="before">`
- this inserts the block before the [target div](https://github.com/odoo/odoo/blob/1ace23afe8a937fc1dc53879f33ca591fd5d25b8/addons/point_of_sale/receipt/pos_order_receipt.xml#L70-L86), which is independent of
  the `basic_receipt` flag, causing the block to always be visible

[1] https://github.com/odoo/enterprise/commit/a0c4f841cde0fcfda0a0c57f865f0eff6b6d6afe

Fix:
- place the block so it is shown only when `basic_receipt` is false
- update the xpath expression to `prices` div ( here `basic_receipt` is false
  `//div[@name='prices']` with `position="inside"`
  
After fix (for full receipt)
<img width="257" height="349" alt="image" src="https://github.com/user-attachments/assets/3932cae1-3ceb-42ad-9ce4-16a9bd4fea7d" />



  opw-6383358

Forward-Port-Of: odoo/enterprise#125118

Description of the issue/feature this PR addresses:

The unread counter feeding the PWA app badge is written to the `odoo-mail-unread-db`
IndexedDB database, through a connection opened once, at module load, and cached for the
life of the page by the bundled idb-keyval (3.2.0), which cannot reopen it. When the
browser drops the origin's storage (eviction under disk pressure, site data cleared, a
privacy extension purging it), that connection is closed for good, and as
`updateAppBadge()` discards the promise returned by `idbKeyval.set()`, the rejection
reaches the user as a client error dialog.

Reported in production on a backend tab left open overnight (Firefox, 19.0):

```
UncaughtPromiseError > InvalidStateError
Uncaught Promise > IDBDatabase.transaction: Can't start a transaction on a closed database
```

Reproduced on a demo database below, with `?debug=assets` so that the stack points at the
source: lines 23 and 24 of the vendored idb-keyval are the `db.transaction()` call of
`_withIDBStore`, on the connection cached at module load.

<img width="1600" height="590" alt="error-dialog-debug" src="https://github.com/user-attachments/assets/e2b1aa46-501a-43d4-b4c0-20def1f529ef" />

Current behavior before PR:

1. log into the backend and leave the tab open
2. in the devtools, Application > Storage, tick *only* "IndexedDB" and click "Clear site
   data", as the browser itself does when it evicts the origin (the session cookie is left
   untouched, so the tab keeps working)
3. receive a message, or do anything else that changes the unread counter

The dialog opens, and opens again on every counter update for the whole life of the tab,
since the dead connection is never replaced; the counter is not saved any more either.

Two variants of the same code: the write also rejects, without anything being cleared,
when the origin runs out of storage quota (`QuotaExceededError`), and when the browser
forbids storage for the origin, `indexedDB.open()` throws during module evaluation, so
`store_service_patch.js` fails to load entirely.

Desired behavior after PR is merged:

The store is opened lazily, dropped whenever saving the counter fails, and the write is
retried once on a new connection: a single counter update after the connection was closed
saves it again. Opening the database is guarded too, for the synchronous throw. When the
retry fails as well the error is ignored, the app badge being cosmetic.

`mail/static/tests/web/app_badge.test.js` covers the retry, the recovery of a permanently
closed connection, and the database that cannot be opened at all. The three tests fail on
the current code with the uncaught `IDBDatabase.transaction` error.

Introduced in 19.0 by c04c4cb715902fe95618a15e18233cd001bdb304, and identical from
saas-19.1 to master, hence this PR against 19.0.

The corporate CLA for ERPVibe Limited is submitted in #283477.

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

Forward-Port-Of: odoo/odoo#283480