**Description of the problem**
The age verification popup snippet (`s_age_verification_popup`) does not work properly when dropped into the `#product_details` element of a product page. In particular, the popup is rendered below the blurred background and cannot be interacted with (it should be rendered above the blur instead).

**How to reproduce**
1. Open a product page.
2. Drop `s_age_verification_popup` into the product details.
3. The popup is rendered below the blurred background.

**Why the problem happens**
The `s_age_verification_popup` snippet applies the blur effect to the `#wrapwrap` element. The popup is expected to be rendered above the blur thanks to its `z-index`.
However, `z-index` only applies within the same stacking context. A child element cannot be rendered above elements outside its parent's stacking context, regardless of how high its own `z-index` is. Since `#product_details` has a defined `z-index`, it creates a stacking context. As a result, the popup, which is a child of `#product_details`, is rendered below the blur element.

**Fix**
This commit adds an SCSS rule to `#product_details` so that it no longer creates a stacking context when it contains an open age verification popup. To prevent the stacking context from being created, `z-index` is set to `auto` and `position` to `relative`.

task-6358990

Forward-Port-Of: odoo/odoo#275368

When a push subscription is renewed by the browser (typically every few days), the pushsubscriptionchange event fires and the service worker attempts to re-register the new subscription endpoint via register_devices(). However, the VAPID public key was missing from the request kwargs.

The server-side register_devices() always validates the VAPID key first and raises InvalidVapidError when it is absent. This caused the renewed subscription to never be saved in the database, silently breaking push notifications after the first subscription renewal.

Fix by extracting the applicationServerKey from the new subscription's options and encoding it as a base64url string (without padding) — matching the existing logic in webclient.js _arrayBufferToBase64().

Description of the issue/feature this PR addresses:

Current behavior before PR: Subscriptions don't get renewed causing push notifications to stop eventually.

Desired behavior after PR is merged: Subscriptions get renewed successfully.


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

Forward-Port-Of: odoo/odoo#276085
Forward-Port-Of: odoo/odoo#275217

The partner credit limit warning on quotations and customer invoices depends on which company the user is currently working in, instead of the company of the document itself.

Steps to reproduce:
- Enable Sale Credit Limit in the settings of My Company (San Francisco)
- Set a Credit Limit of 100 on a customer, e.g. Deco Addict
- Create a draft quotation of 500 for that customer => The credit limit warning banner is displayed, as expected
- Switch the active company to any other company, for example My Company (Chicago), keeping access to both companies
- Open the same quotation again => The warning banner is gone, although neither the quotation nor the
   customer changed

The credit fields used to build the warning are evaluated against the user's active company: credit_limit is a company-dependent field, and credit / credit_to_invoice are computed on the receivables of the current company. When the active company is not the document's company, the warning is checked against the wrong ledger and the wrong limit, so it can disappear on an over-limit customer or show up for a healthy one.

Both computes already contain the line that was meant to handle this, but the result of with_company() was discarded, making it a no-op. Assign it, as every other compute in these files already does, so the warning is always evaluated in the document's company.

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

Forward-Port-Of: odoo/odoo#276917
Forward-Port-Of: odoo/odoo#276308

Problem: When importing XML files to generate vendor bills, the system uses UBL parser and assumes that the PriceAmount node needs to be divided by the BaseQuantity node to obtain the exact price unit. However, in Colombia, the DIAN treats the PriceAmount node as the exact price unit. This was not flagged in the system so the parser incorrectly divides the PriceAmount by BaseQuantity, resulting in negative discounts to be added to match the subtotal.

Solution: Extract the basis_qty logic into a helper method so
other localizations can override when needed.

Current behavior: When importing a Colombian XML with a product that has a BaseQuantity greater than 1, the PriceAmount gets incorrectly divided, resulting in negative discounts on the vendor bill.

Expected Behavior: When importing a Colombian XML with a product that has a BaseQuantity greater than 1, the PriceAmount gets parses as the exact unit price with no negative discounts applied.

Task [link](https://www.odoo.com/odoo/project.task/6215466)
task-6215466

Forward-Port-Of: odoo/odoo#276763
Forward-Port-Of: odoo/odoo#273129

Steps to reproduce:
- Create a promotions program with a rule granting 1 point per currency unit spent (minimum 2 items and 50.00 spent) and a reward "10% discount on the cheapest product" for 1 point
- Open a PoS session and add 2 products to trigger the program
- Keep adding products to the order

Issue:
A new "10% on the cheapest product" line is added for every product added. In eCommerce and Sales the discount is only applied once.

Cause:
The rule grants far more points than the reward costs, so the reward remains claimable after being applied. The auto-claim loop of `updateRewards` therefore re-applies it on every order change, stacking one discount line per change. The already-applied check in `getClaimableRewards` only covered 'coupons' programs, while `_get_claimable_rewards` in sale_loyalty also skips discount rewards already present on the order lines.

Solution:
When auto-claiming, skip discount rewards that are already applied on the order, unless they belong to a payment program (ewallet, gift card). The reward can still be claimed manually several times through the Reward button by spending more points.

opw-6380421

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

Forward-Port-Of: odoo/odoo#276300

Steps to reproduce:
- Create a partner without pincode
- Create a picking and Challan for that partner
- Click print

Will result in the following traceback-
```py
Traceback (most recent call last):
  File "<1103>", line 710, in template_l10n_in_ewaybill_report_ewaybill_1103
  File "<1103>", line 692, in template_l10n_in_ewaybill_report_ewaybill_1103_content
  File "<1103>", line 674, in template_l10n_in_ewaybill_report_ewaybill_1103_t_call_0
  File "<1103>", line 86, in template_l10n_in_ewaybill_report_ewaybill_1103_t_call_1
  File "/home/odoo/odoo18/community/addons/l10n_in_ewaybill/models/l10n_in_ewaybill.py", line 727, in _ewaybill_generate_direct_json
    **self._prepare_ewaybill_base_json_payload(),
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/odoo18/community/addons/l10n_in_ewaybill_stock/models/l10n_in_ewaybill.py", line 289, in _prepare_ewaybill_base_json_payload
    ewaybill_json = super()._prepare_ewaybill_base_json_payload()
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/odoo18/community/addons/l10n_in_ewaybill/models/l10n_in_ewaybill.py", line 669, in _prepare_ewaybill_base_json_payload
    **prepare_details(
      ^^^^^^^^^^^^^^^^
  File "/home/odoo/odoo18/community/addons/l10n_in_ewaybill/models/l10n_in_ewaybill.py", line 641, in prepare_details
    f"{place}{key}": fun(partner, place) if key == "StateCode" else fun(partner)
                                                                    ^^^^^^^^^^^^
  File "/home/odoo/odoo18/community/addons/l10n_in_ewaybill/models/l10n_in_ewaybill.py", line 674, in <lambda>
    "Pincode": lambda p: int(p.zip) if p.country_id.code == "IN" else 999999,
                         ^^^^^^^^^^
ValueError: invalid literal for int() with base 10: ''
```
In this commit, we resolve the traceback


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

Forward-Port-Of: odoo/odoo#276180

Problem: When importing XML files to generate vendor bills, the system uses UBL parser and assumes that the PriceAmount node needs to be divided by the BaseQuantity node to obtain the exact price unit. However, in Colombia, the DIAN treats the PriceAmount node as the exact price unit. This was not flagged in the system so the parser incorrectly divides the PriceAmount by BaseQuantity, resulting in negative discounts to be added to match the subtotal.

Solution: Extract the basis_qty logic into a helper method so
other localizations can override when needed.

Current behavior: When importing a Colombian XML with a product that has a BaseQuantity greater than 1, the PriceAmount gets incorrectly divided, resulting in negative discounts on the vendor bill.

Expected Behavior: When importing a Colombian XML with a product that has a BaseQuantity greater than 1, the PriceAmount gets parses as the exact unit price with no negative discounts applied.

Task [link](https://www.odoo.com/odoo/project.task/6215466)
task-6215466

Forward-Port-Of: odoo/odoo#276763
Forward-Port-Of: odoo/odoo#273129

The `account_journal_type.bank` KPI (surfaced by the Databases app as `account_journal_type_bank`, tooltip "Draft entries in journal Bank") is meant to report journal entries in bank journals that still need attention: drafts, posted-but-unchecked entries, and posted bank entries that are not yet reconciled.

The "not yet reconciled" case was implemented as:

    ```LEFT JOIN account_bank_statement_line st_line
           ON move.statement_line_id = st_line.id
    AND (st_line.id IS NULL OR NOT st_line.is_reconciled)```

`st_line.id IS NULL` does not only match unreconciled bank transactions, it also matches any posted move booked directly in a bank journal that never originated from an imported bank statement line (manual entries, bank fees, opening balances, ...). Those moves have no `statement_line_id` by design and can never be reconciled, so they were counted as "pending" forever, permanently inflating the KPI for any database with such entries.

Only require an actual bank statement line before flagging it as unreconciled, matching the logic already used for the "to reconcile" count on the journal dashboard (account_journal_dashboard.py).

opw-6199785





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

`qty_available` is by default not computed with sudo, while the `total_value` is. This means that in `_update_standard_price`, the customer configuration can have a negative impact on the standard_price compute.

For example, if a user create a custom rule so that specific users have access to specific warehouses only, compute `total_value / qty_available` can actually mean `global_total_value / partial_qty_available`, which creates an aberrant standard price.

To fix this issue, the _update_standard_price must be done in sudo.

OPW-6243363

---

## Test result without fix
```
2026-06-17 12:24:50,810 47572 ERROR oes_test_19 odoo.addons.stock_account.tests.test_stockvaluation: FAIL: TestStockValuation.test_update_standard_price_with_limited_access_users
Traceback (most recent call last):
  File "/home/odoo/Odoo/src/19.0/odoo/addons/stock_account/tests/test_stockvaluation.py", line 3624, in test_update_standard_price_with_limited_access_users
    self.assertEqual(product.standard_price, 1.0)
AssertionError: 12.11111111111111 != 1.0
 ```

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

Forward-Port-Of: odoo/odoo#270559

Steps to reproduce:
- Create a partner without pincode
- Create a picking and Challan for that partner
- Click print

Will result in the following traceback-
```py
Traceback (most recent call last):
  File "<1103>", line 710, in template_l10n_in_ewaybill_report_ewaybill_1103
  File "<1103>", line 692, in template_l10n_in_ewaybill_report_ewaybill_1103_content
  File "<1103>", line 674, in template_l10n_in_ewaybill_report_ewaybill_1103_t_call_0
  File "<1103>", line 86, in template_l10n_in_ewaybill_report_ewaybill_1103_t_call_1
  File "/home/odoo/odoo18/community/addons/l10n_in_ewaybill/models/l10n_in_ewaybill.py", line 727, in _ewaybill_generate_direct_json
    **self._prepare_ewaybill_base_json_payload(),
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/odoo18/community/addons/l10n_in_ewaybill_stock/models/l10n_in_ewaybill.py", line 289, in _prepare_ewaybill_base_json_payload
    ewaybill_json = super()._prepare_ewaybill_base_json_payload()
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/odoo18/community/addons/l10n_in_ewaybill/models/l10n_in_ewaybill.py", line 669, in _prepare_ewaybill_base_json_payload
    **prepare_details(
      ^^^^^^^^^^^^^^^^
  File "/home/odoo/odoo18/community/addons/l10n_in_ewaybill/models/l10n_in_ewaybill.py", line 641, in prepare_details
    f"{place}{key}": fun(partner, place) if key == "StateCode" else fun(partner)
                                                                    ^^^^^^^^^^^^
  File "/home/odoo/odoo18/community/addons/l10n_in_ewaybill/models/l10n_in_ewaybill.py", line 674, in <lambda>
    "Pincode": lambda p: int(p.zip) if p.country_id.code == "IN" else 999999,
                         ^^^^^^^^^^
ValueError: invalid literal for int() with base 10: ''
```
In this commit, we resolve the traceback


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

Forward-Port-Of: odoo/odoo#276180

Steps to reproduce:
- Create a partner without pincode
- Create a picking and Challan for that partner
- Click print

Will result in the following traceback-
```py
Traceback (most recent call last):
  File "<1103>", line 710, in template_l10n_in_ewaybill_report_ewaybill_1103
  File "<1103>", line 692, in template_l10n_in_ewaybill_report_ewaybill_1103_content
  File "<1103>", line 674, in template_l10n_in_ewaybill_report_ewaybill_1103_t_call_0
  File "<1103>", line 86, in template_l10n_in_ewaybill_report_ewaybill_1103_t_call_1
  File "/home/odoo/odoo18/community/addons/l10n_in_ewaybill/models/l10n_in_ewaybill.py", line 727, in _ewaybill_generate_direct_json
    **self._prepare_ewaybill_base_json_payload(),
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/odoo18/community/addons/l10n_in_ewaybill_stock/models/l10n_in_ewaybill.py", line 289, in _prepare_ewaybill_base_json_payload
    ewaybill_json = super()._prepare_ewaybill_base_json_payload()
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/odoo18/community/addons/l10n_in_ewaybill/models/l10n_in_ewaybill.py", line 669, in _prepare_ewaybill_base_json_payload
    **prepare_details(
      ^^^^^^^^^^^^^^^^
  File "/home/odoo/odoo18/community/addons/l10n_in_ewaybill/models/l10n_in_ewaybill.py", line 641, in prepare_details
    f"{place}{key}": fun(partner, place) if key == "StateCode" else fun(partner)
                                                                    ^^^^^^^^^^^^
  File "/home/odoo/odoo18/community/addons/l10n_in_ewaybill/models/l10n_in_ewaybill.py", line 674, in <lambda>
    "Pincode": lambda p: int(p.zip) if p.country_id.code == "IN" else 999999,
                         ^^^^^^^^^^
ValueError: invalid literal for int() with base 10: ''
```
In this commit, we resolve the traceback


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

Forward-Port-Of: odoo/odoo#276180

Before this commit:
- When importing a **UBL** or **Factur-X (CII)** invoice, Odoo determines whether the document should be imported as an invoice or a credit note based on the `TaxExclusiveAmount (UBL)` /` TaxBasisTotalAmount (Factur-X)`.
- In some rare cases, a valid invoice can contain a negative `TaxExclusiveAmount` / `TaxBasisTotalAmount` while still having a positive `TaxInclusiveAmount` / `GrandTotalAmount`. 
- In such situations, Odoo incorrectly imports the document as a credit note.

Technical reason:
- The method `_get_import_document_amount_sign()` uses `TaxExclusiveAmount` / `TaxBasisTotalAmount `to determine whether the imported document is an invoice or a refund.

After this commit:
- **UBL** now uses `TaxInclusiveAmount` instead of `TaxExclusiveAmount`, and **Factur-X** now uses `GrandTotalAmount `instead of `TaxBasisTotalAmount` to determine whether the document should be imported as an invoice or a credit note.
- Prevent valid invoices with negative `TaxExclusiveAmount` / `TaxBasisTotalAmount` from being incorrectly converted into credit notes.

Task-6321262

Forward-Port-Of: odoo/odoo#276307
Forward-Port-Of: odoo/odoo#271829

Steps to reproduce:
- Create a promotions program with a rule granting 1 point per currency unit spent (minimum 2 items and 50.00 spent) and a reward "10% discount on the cheapest product" for 1 point
- Open a PoS session and add 2 products to trigger the program
- Keep adding products to the order

Issue:
A new "10% on the cheapest product" line is added for every product added. In eCommerce and Sales the discount is only applied once.

Cause:
The rule grants far more points than the reward costs, so the reward remains claimable after being applied. The auto-claim loop of `updateRewards` therefore re-applies it on every order change, stacking one discount line per change. The already-applied check in `getClaimableRewards` only covered 'coupons' programs, while `_get_claimable_rewards` in sale_loyalty also skips discount rewards already present on the order lines.

Solution:
When auto-claiming, skip discount rewards that are already applied on the order, unless they belong to a payment program (ewallet, gift card). The reward can still be claimed manually several times through the Reward button by spending more points.

opw-6380421

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

Forward-Port-Of: odoo/odoo#276300

When sending a batch of invoice, we first generate an unique PDF file regrouping every invoice.
When at least one invoice needs more than one page to be rendered entirely, the number of pages will
be greater than the number of invoices.

In this case, we use <hX> tags to split invoices:

https://github.com/odoo/odoo/blob/5ba945cdba6be3ff8838e56784ade16c6200de84/odoo/addons/base/models/ir_actions_report.py#L916-L923

This tag is added for PDF files, using the invoice's title:

https://github.com/odoo/odoo/blob/5ba945cdba6be3ff8838e56784ade16c6200de84/addons/web/views/report_templates.xml#L627

In some localization modules, this title shouldn't be displayed and it is removed. Example for Chile:

https://github.com/odoo/odoo/blob/5ba945cdba6be3ff8838e56784ade16c6200de84/addons/l10n_cl/views/report_invoice.xml#L149

In this case, no `<h3>` tag will be added and an error is raised as we cannot separate invoices.

We propose to add an empty `<h3>` tag if the
document title is not defined.

opw-6281187

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

Forward-Port-Of: odoo/odoo#269100

all_sm is referenced by two branches of the outer UNION, so PostgreSQL materializes it (a CTE used more than once is an optimization fence). Every query on report_stock_quantity therefore builds the forecast for all products/warehouses first and filters afterwards, so predicates like product_id can't reach the stock_move scan.

This hurts single-product lookups such as _read_group() in mrp_report_bom_structure._get_stock_availability(), called repeatedly per component while rendering a BoM report: each call does a full stock_move scan plus two sorts that spill to disk.

Marking all_sm NOT MATERIALIZED lets the planner inline it and push the product_id/warehouse_id filter down to an index scan, removing the full scan, the GENERATE_SERIES expansion and the on-disk sorts. warehouse_cte stays materialized (small and cheap).

Query generated from the _read_group:
```SQL
SELECT MIN("report_stock_quantity"."date")
FROM "report_stock_quantity"
WHERE (
        (
            (
                (
                    ("report_stock_quantity"."state" = 'forecast')
                    AND ("report_stock_quantity"."date" >= '2026-07-08')
                )
                AND ("report_stock_quantity"."product_id" = 15743)
            )
            AND ("report_stock_quantity"."product_qty" >= 1.0)
        )
        AND ("report_stock_quantity"."warehouse_id" = 4)
    )
    AND ("report_stock_quantity"."company_id" IN (1))
```

Before:
800 ms by _read_group in _get_stock_availability().
For opening a BoM overview with hundred of components takes 17 sec.

After:
25 ms by _read_group in _get_stock_availability().
Same BoM overview drops to 3 sec to open.

cc @Aurelienvd 



I can send you EXPLAIN ANALYZE, but I prefer to not putting them here to avoid data leakage.

Forward-Port-Of: odoo/odoo#275457
Forward-Port-Of: odoo/odoo#275022

Before this commit, validating transfers of several companies at once could assign a lot of one company to the move lines of another one, because the search for existing lots used a variable left over from a previous loop (the last move line iterated) instead of the company of the group of lines being checked.

Steps to reproduce:
- in a multi-company database, create a product tracked by lots
- create a lot with the same name for that product in each company
- create one receipt per company with that lot name typed in the detailed operations, select both receipts in the Transfers list view and validate them together

The lines of one company are linked to the lot of the other company and the validation is blocked by "Incompatible companies on records". When the lot only exists in one of the companies, the search misses it and the validation fails on the lot uniqueness constraint while recreating a lot that already exists.

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

Forward-Port-Of: odoo/odoo#276688

**Problem:**
After partially invoicing a timesheet-delivered sale order line, a second invoice for the remaining delivered quantity can no longer be created.

**Steps to reproduce:**
1. Install Sales and Timesheets
2. Sell a service invoiced on delivered timesheets
3. Log a timesheet covering the whole period
4. Create an invoice, reduce its quantity to part of the delivered amount, and post it
5. Create an invoice again for the rest

**Current behavior:**
"Cannot create an invoice. No items are available to invoice." is raised, even though qty_delivered - qty_invoiced is still positive.

**Expected behavior:**
A second invoice is created for the remaining delivered quantity.

**Cause of the issue:**
Since opw-6001094, `_recompute_qty_to_invoice` runs on every invoice creation, not only when a timesheet period is provided. It re-derives `qty_to_invoice` from un-invoiced timesheets alone. Posting the first invoice already linked every timesheet of the line (the linking ignores the invoiced quantity), so no un-invoiced timesheet is left, and `qty_to_invoice` is forced to 0 — discarding the still-billable remainder.

**Fix:**
Forcing the quantity to zero is only meaningful when the invoice is restricted to a timesheet period, where a line whose timesheets all fall outside that period genuinely has nothing to invoice. Without a period, the standard delivered-versus-invoiced quantity is the authoritative measure of what remains to bill, so the timesheet-based recomputation must not override it.

opw-6295941