**Steps to reproduce:**
* Install the *l10n_cl* module with demo data.
* Switch the environment to the **CL** company.
* Create a customer invoice containing at least one invoice line.
  Enter a **price_unit with decimals** (e.g., *99.56*).
* Confirm the invoice.
* Download and open the generated PDF from the invoice form.

**Observed behavior:**
* The **unit price** rendered in the PDF is displayed as a rounded
  decimal value (e.g., *100.00*), even though *Chilean* localization
  does **not** use decimal representation for unit prices.

**Cause:**
* The QWeb template uses `t-options` to format float values with
  **two-decimal precision**, forcing decimals to appear in the PDF.

**Fix:**
* Reduce the formatting precision in the PDF template so that **no
  decimal points** are displayed, matching Chilean localization rules.
  
 
**Before Fix**
<img width="783" height="319" alt="image" src="https://github.com/user-attachments/assets/e5ea5a38-a77a-4d64-9aae-672940734ea4" />


 **After Fix**
<img width="794" height="316" alt="image" src="https://github.com/user-attachments/assets/c47d2f0a-b4ea-428e-bf57-23584c34bf5c" />

---

opw-5234563

Forward-Port-Of: odoo/odoo#238059

Before this commit:
migration script only creates a new tax group.

After this commit:
migration script will create all tax groups that are required for  new taxes if they do not already exist

Why:
During the migration if the tax group is not found then the value error is raised

There are 2 reason of why the tax group is not found :
1. User deletes it by themselves
2. In the upgrade script of account in version saas~16.2.1.2 the pre-migrate script where global scope of tax groups was converted to company-specific, [Ref](https://github.com/odoo/upgrade/blob/b4f278aa9f32dc5edab814af0c2a0339cd7400a6/migrations/account/saas~16.2.1.2/pre-migrate.py#L173) If the tax groups are not associated with any tax or any account_move_line then it is deleted.


User Traceback : 
`  File "/home/odoo/src/odoo/17.0/odoo/addons/base/models/ir_model.py", line 2203, in _xmlid_lookup
    raise ValueError('External ID not found in the system: %s' % xmlid)
ValueError: External ID not found in the system: account.1_l10n_id_tax_group_non_luxury_goods`


account_tax_group records in production : 
```
kdes_3444743=> select id,name from account_tax_group;
 id |                             name                              
----+---------------------------------------------------------------
  1 | {"en_US": "Taxes", "id_ID": "Pajak"}
  2 | {"en_US": "Luxury Good Taxes", "id_ID": "Pajak Barang Mewah"}
  3 | {"en_US": "Non-luxury Good Taxes", "id_ID": "Pajak Barang"}
  4 | {"en_US": "Zero-rated Taxes", "id_ID": "Pajak Nol"}
  5 | {"en_US": "Tax Exempted", "id_ID": "Bebas Pajak"}
(5 rows)
```

Query executed [here](https://github.com/odoo/upgrade/blob/b4f278aa9f32dc5edab814af0c2a0339cd7400a6/migrations/account/saas~16.2.1.2/pre-migrate.py#L152) : 
```
        WITH company AS (
            SELECT "company_id" AS id,
                   "tax_group_id" AS tg_id
              FROM "account_move_line"
             WHERE "company_id" IS NOT NULL
               AND "tax_group_id" IS NOT NULL
             UNION 
            SELECT "company_id" AS id,
                   "tax_group_id" AS tg_id
              FROM "account_tax"
             WHERE "company_id" IS NOT NULL
               AND "tax_group_id" IS NOT NULL
        )
        INSERT INTO account_tax_group ("country_id", "create_date", "create_uid", "name", "preceding_subtotal", "sequence", "write_date", "write_uid", company_id, _tmp_orig_id)
             SELECT "tg"."country_id", "tg"."create_date", "tg"."create_uid", "tg"."name", "tg"."preceding_subtotal", "tg"."sequence", "tg"."write_date", "tg"."write_uid", company.id, tg.id
               FROM account_tax_group tg,
                    company
              WHERE company.tg_id = tg.id
```


Above selection query on user's DB :
```
kdes_3444743=> SELECT "company_id" AS id,
                   "tax_group_id" AS tg_id
              FROM "account_move_line"
             WHERE "company_id" IS NOT NULL
               AND "tax_group_id" IS NOT NULL
             UNION 
            SELECT "company_id" AS id,
                   "tax_group_id" AS tg_id
              FROM "account_tax"
             WHERE "company_id" IS NOT NULL
               AND "tax_group_id" IS NOT NULL;
 id | tg_id 
----+-------
  1 |     1
  1 |     2
(2 rows)

```
As only 2 tax groups are associated with the account_move_line and account_tax
They are only being inserted to the able along with the company id prefix and company_id field set
, remaining enteries are deleted in [next query](https://github.com/odoo/upgrade/blob/b4f278aa9f32dc5edab814af0c2a0339cd7400a6/migrations/account/saas~16.2.1.2/pre-migrate.py#L173).

Same is the case with the records in [ir_model_data](https://github.com/odoo/upgrade/blob/b4f278aa9f32dc5edab814af0c2a0339cd7400a6/migrations/account/saas~16.2.1.2/pre-migrate.py#L174-L196). 

OPW : 5358546
UPG : 3444743

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

Forward-Port-Of: odoo/odoo#238981

In #92208 the CAF system was improved to find the next starting value in the right sequence if there are multiple in the system. If no CAFs are found, it will reset to the document types starting number.

This worked except in the case where there are multiple CAFs that are currently marked active in a document type. As it tries to access `caf.start_nb` it hits an ensure_one() which throws a traceback whenever you open most account.moves on the DB.

Steps to reproduce:
- Modify the CAF for Doc Type 33 (Electronic Invoices) to have a smaller range than 1 - 999,999 (1 - 5)
- Create Two new CAF files also for Doc Type 33 that start after this value (6 - 10 and 11 - 15 for example).
- Mark the original to be spent via cancelling it and try to open an invoice. It will find both of the new CAFs and try to get the start_nb of the recordset.

In discussion with the PO, when we have multiple CAFs, we should pick by the lowest start number as it will allow for any gaps that might exist be filled.

opw-5414350

Forward-Port-Of: odoo/enterprise#102385

- Before saas-18.4, the [out-of-stock](https://github.com/odoo/odoo/blob/saas-18.3/addons/website_sale_stock/static/src/xml/website_sale_stock_product_availability.xml#L8) message was rendered as plain text without
any layout-specific classes, allowing the message to wrap naturally.

**Reference of version saas-18.3**
<img width="1920" height="768" alt="2025-12-16_18-53" src="https://github.com/user-attachments/assets/d7670fa4-6808-40d7-9bad-768d0637f366" />

- From saas-18.4, the [out-of-stock](https://github.com/odoo/odoo/blob/saas-18.4/addons/website_sale_stock/static/src/xml/website_sale_stock_product_availability.xml#L13-L16) message is rendered using `t-out`, which outputs plain text and collapses line breaks, causing the message to appear on a single line and overflow when used with `d-inline-flex`.
See screenshots in the PR description (Before fix).
<img width="1920" height="672" alt="2025-12-16_14-28" src="https://github.com/user-attachments/assets/927080cd-f2b0-45cd-ae0a-2917699c05f6" />

- Updated the layout to replace `d-inline-flex` with `d-flex` and apply `text-break` on the message container so long and dynamic texts wrap correctly inside the badge.
See screenshots in the PR description (After fix).
<img width="1918" height="682" alt="2025-12-16_14-31" src="https://github.com/user-attachments/assets/2cafdc61-e494-468a-9d41-08ab3c83b041" />


opw-5274850

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

Issue: YouTube has changed its referrer policy to enforce "strict-origin-when-cross-origin". 
Without this, it can throw a 153 error and block the video.

To replicate in runbot ,add "<meta name="referrer" content="no-referrer"/>" to any major page like the main layout or footer. This sets it for the entire page. 
Therefore, to enforce YouTube's calls to have the proper referrerpolicy, I hardcoded it directly.

Fix:
added 'referrerpolicy="strict-origin-when-cross-origin"' to the iframe.

opw-5239363


Description of the issue/feature this PR addresses:
Our website allows for customization, including the ability to modify meta tags. In ticket#523963, the customer added "<meta name="referrer" content="no-referrer" />" which forced all calls to be set with referrerpolicy="no-referrer" when it's required to have 'referrerpolicy="strict-origin-when-cross-origin"' for embeded videos to youtube

Current behavior before PR:
If a customer sets "<meta name="referrer" content="no-referrer" />" on any page, YouTube blocks it on that page; if it's in the header or footer, the entire website is then blocked. 

Desired behavior after PR is merged:
After it now enforces the call to have 'referrerpolicy="strict-origin-when-cross-origin"' even if the tag <meta name="referrer" content="no-referrer" />". Allowing YouTube to be used. 



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

Forward-Port-Of: odoo/odoo#237182

Issue
=====
When scanning a package as result package, if the package is empty, it works, but if this package already has content, it doesn't work.

How to reproduce
================
1. Enable "Packages" and "Storage Locations" settings;
2. Create two packages with some content in WH/Stock/Shelf 1;
3. Create an empty package;
4. Create an internal transfer directly from the Barcode app;
5. Scan Shelf 1 barcode and scan first package;
6. Scan the empty package => It's assigned as the result package;
7. Confirm the operation;
8. Create another internal transfer;
9. Scan Shelf 1 barcode and scan second package;
10. Scan the no more empty package => This time, it's not assigned as the result package.

Reason
======
A package was assigned as the result package only if one of the following conditions is matched:
1. The scanned package is empty (it's what's happening in 6.);
2. The selected line has no result package yet and the scanned package is in the selected line's destination location.

Here, it doesn't work because since we move a package, the barcode line has already a destination package (the same then the source package.)

Fix
===
For the condition 2., adapt the condition to make it works too if the selected line has the same package as the source and result package.

[opw-5326234](https://www.odoo.com/odoo/project/49/tasks/5326234)

Forward-Port-Of: odoo/enterprise#102051
Forward-Port-Of: odoo/enterprise#101357

**Steps to reproduce:**
* Install the **Accounting** and **l10n_sa_edi** modules.
* Go to `Sales` journal and in ZATCA section click on **Re-Onboard**.
* Create Tax with 15% tax with **included price** set as **tax-included**.
* Create a customer invoice.
* Set **price_unit = 200**, **quantity = 7**, with **15% tax included** and confirm the invoice.
* Generate the **ZATCA XML** by clicking **Process Now** in the info banner displayed above the invoice.
* Submit the XML to **ZATCA validation**.

**Observed behavior:**
* ZATCA validation fails with error **BR-KSA-EN16931-11**
* The XML uses **PriceAmount (BT-146)** rounded to **2 decimals** (e.g., 173.91).
* ZATCA computes: **173.91 × 7 = 1217.37**, but the XML’s **LineExtensionAmount (BT-131)** is **1217.39**, creating a mismatch and triggering validation failure.

**Cause:**
* In v19, `_add_document_line_price_nodes()` inherited from `account.edi.xml.ubl_20` uses `float_round` with **product_price_dp = 2 decimals** for **PriceAmount**.
* This precision is insufficient when ZATCA recalculates totals for tax-included prices, causing rounding discrepancies.

**Fix:**
* Override `_add_document_line_price_nodes()` in **l10n_sa_edi** to round `gross_price_unit_currency` to **10 decimal places** instead of 2.
* Ensures PriceAmount has sufficient precision to satisfy ZATCA validation rules.

opw-5346886

For the `Türkiye` localization, sending an invoice by email with a recipient bank causes an error.

Steps to reproduce:
1) Install `accountant` and `l10n_tr_nilvera_einvoice` modules with demo data. 
2) Switch to TR Company.
3) Create a customer with country set to `Türkiye`.
4) Open the TR company contact and on the Accounting page edit an existing bank
   account, add a new bank (e.g., 'Test-Bank'), and set `Send Money` to
   `Trusted`.
5) Create an invoice for the customer, confirm it, and send it by email.

ref video: https://drive.google.com/file/d/1OoUzJ-Dr2uuy4yk9P-CKUS0L6OSgeyJ3/view?usp=sharing

Error:
KeyError: 'country_id'

Root Cause:
When sending the invoice, the system generates the invoice XML. In the method `_get_address_node` (see [1]), there is a special case to determine the correct country for `res.bank`. However, when `vals['partner']` is a `res.bank` record, no `model` is provided in `vals`, so it defaults to `res.partner`. The code then attempts to access `partner['country_id']`, which does not exist on `res.bank`, raising the error.

FIX:
Ensure the `model` is set to `res.bank` when `vals['partner']` is a `res.bank` record, ensuring the correct country value is used.

[1]- https://github.com/odoo/odoo/blob/0190bb7faca1dd5ce38dfdacbb8fa446f06d59a3/addons/l10n_tr_nilvera_einvoice/models/account_edi_xml_ubl_tr.py#L165-L181

opw-5103598

## Issue:
When exporting the XML for a VAT return, the client nihil field was incorrectly set to YES
According to Belgian regulations, this is only allowed on the last report of the calendar year
https://finances.belgium.be/sites/default/files/downloads/165-625-directives-2019.pdf

## Cause:
Prior to 18.3, nihil was a checkbox option on export
Since 18.3, it is automatically selected based solely on a price formula, without checking the report’s date

This PR brings back the Client Nihil checkbox in 19.0
But didn't change the default value
Causing the issue to still be present
https://github.com/odoo/enterprise/pull/99496

## Steps to reproduce:
- Select the Belgian company
- Open the Tax Return and select the VAT Return
- Click Returns and enter an opening date in January
- Click Review for the first available report
- Ignore errors and return to previous page
- Click on Submit -> Download XML
- Before the fix, ClientListingNihil is set to YES

## Potential remaining issue:
The legal document specify that it should also be checked in case of "cessation d’activité"
So it may be interesting to consider adding the option back

opw-5184056

Forward-Port-Of: odoo/enterprise#98982

**Behavior:**
Currently Intrastat reports are exported from the account.return view, and will be exported specifically in their extended mode and will contain both arrivals and dispatches. This causes issues for some users that want more specific formats like standard over extended, only arrivals/dispatches or both, etc... And this can cause them to not be able to submit their reports.

The solution is to currently reenable the user to export their report to XML from a cog menu in the Intrastat Report view. While still leaving the current flow through account.return possible, until a better solution is thought of.

**Steps to reproduce:**
- Connect to a company under Belgian Localisation.
- Create a product and, under the Accounting tab, specify a Commodity code (eg Live asses) and Country of Origin (Belgium)
- Create an Invoice containing the product to a Client in another EU Country (eg Luxembourg) and under the  'Other Info' tab, specify Intrastat Countrt (Belgium) - You can choose to leave out Intrastat Transport Mode and Incoterm, this will make the resulting XML have some  missing informations
- Create a Bill with the product with the same settings
- If you go to Intrastat Report, after changing the 'Report' filter to Intrastat (Goods) you will now be able to see an arrival and a dispatch. The extended mode filter is enabled by default, if you didnt fill Intrastat Transport Mode and Incoterm, you will see these missing.
- From this view there is currently no way to export the XML, to do that click the Returns button (select an Opening Date for accounting if needed), click on 'New' and specify Intrastat in the Return Type and a time window containing your Invoice and Bill.
- Then you will see an Intrastat Report show up and after selecting Review, then Submit, you will be able to download the XML. which will contain dispatches and arrivals and will be in Extended Mode. Which, if missing Transport/Incoterm, will fail when submitted to OneGate

opw-5347238

**Current behavior before PR:**

- When dragging and dropping elements with attributes and classes, any non-whitelisted attributes and classes were removed during the `cleanForPaste` process. This caused structural issues and loss of formatting after the drop.

- When an image had a caption and only the image was selected and cut, the image was removed but the caption incorrectly remained

- When dragging and dropping an image without an active selection on the image, the image was not removed during the drop. This resulted in the image being duplicated, one at the original position and another at the drop location.

- When selecting an image with a caption and performing copy-paste, only the image was copied and pasted.

**Desired behavior after PR is merged:**

- An `application/vnd.odoo.odoo-editor` dataTransfer type is now set during `dragstart` for editor elements. As a result, we no longer need to clean the `dataTransfer` content during drop, preserving the original structure and preventing the loss of attributes and classes.

- Cutting an image that contains a caption now correctly removes both the image and its associated caption.

- The image is now selected on pointerdown event . As a result, when the image is dropped, deleteSelection correctly removes the original image before inserting the new one, preventing duplication.

-  Now, when an image with a caption is selected and copy-pasted, the entire image along with its caption is correctly copied and pasted.


task: 4914451

## Versions
saas-18.3 > saas-18.4
Backport of OE's commit c02eb8584da1cef7d28310d9be947b56a38a5cbd

## Issue
A customer subscribing to a service can checkout without filling its data (incl. country). This leads to a failure of the next payment and a message in the chatter telling that "Automatic payment failed. No country specified on payment_token's partner".

## Steps to reproduce
*Ensure Sales app is installed*
- Create a customer account without filling personal data in;
- Navigate to the shop:
  - Look for a subscription service (ending with "SUB") and add it to cart;
  - Go to the cart and click the checkout button (automatically bypassing the addresses form);
  - Pay with Demo.
- Logout and sign in as admin user:
  - Go to Sales and open the latest SO (related to the test user):
    - Duplicate the SO and activate debug mode;
    - Open "Other Info" tab:
      - Change the subscription starting date for any date in the past;
      - Set the Payment Token selecting the available one; - Confirm the order.
- Navigate to Scheduled Actions:
  - Look for "Sale Subscription: generate recurring invoices and payments" action and open it:
    - Click "Run Manually".
- Come back to the duplicated subscription SO and look at the chatter's last message:
  - OdooBot's message tells that "Automatic payment failed. No country specified on payment_token's partner".

## Cause
Task 4307281 introduced address info bypass to fasten checkout for services but subscriptions, even for services, require the country to be set for recurring payments as per https://github.com/odoo/enterprise/blob/f40e24e67a1664a13acdd01578d8269d084ee421/sale_subscription/models/sale_order.py#L1751-L1757

opw-5412037

Forward-Port-Of: odoo/enterprise#102168

Two related overlay reposition issues are solved separately out of iframe and in the iframe.

**Commit 1:**
[FIX] html_editor: avoid wrong range after insert and popover reposition

Before this commit: The link popover is repositioned at the beginning of the
text when editing url. When insert, we first delete the non-collapsed selection,
then we split the text node by splitTextNode at the collapsed selection. However,
splitTextNode resets the text node's value by its substring, which breaks the
range of the collapsed selection. This range is stored and used to reposition
the overlay when the selection is not in the editable.

Reproduction:
1. selection some text, create a link
2. go the the url field and type something
3. the popover is replaced to the beginning of the text.

After this commit: we use dom function splitText to split the text only when we
need to, e.g. when the currently selection's offset isn't at the beginning or
the end of the text node. The dom function keeps the range properly maintained
after splitting.

However, there is a limitation case from how we create the link on selection,
how the browser manages the selection's range and how the overlay reacts to it.

The limitation case is when the selection is inside one text node and selecting
the whole text node of the range's startContainer (which is the same with
endContainer). When the link is created, we do extractContent on the selection's
range, put it in the link and insert the link at the collapsed selection. During
this process, the browser loses the range's start/end container which leads to
invalid start/end container.

For this range isn't valid case, it triggers the overlay plugin's special
handler which inserts one shadow caret (which is after the inserted link) and
uses it to calculate the position. Because the shadow caret is inserted by the
cloned collapsed range, we can't really have enough context from the range
(about where to re-place the caret) to manipulate the position.


**Commit2:**
[FIX] html_editor: pass selection data to overlay to avoid reposition in iframe

Before this commit: the overlay plugin uses the editable's document's selection
to check if the current selection is in the editable. It works when there's no
iframe, as the overlays are part of the document. However in an iframe's
editable zone, e.g. the website editing zone, the overlays are not under the
iframe document but under the outer window's document. When checking iframe
document's selection, it cannot detect the selection in the overlay, which gives
a wrong "inEditable" value.

After this commit: we pass the getSelectionData to the overlay so it can use the
existing currentSelectionIsInEditable

task-5184799


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

Steps to reproduce [18.2+]:

1. Add a dynamic snippet to a website page (e.g., Events).

2. Unpublish all event records.

3. The snippet first appears with a visible header, which then
disappears.

[A]- Starting from [1], the `o_dynamic_empty` class was introduced to
handle the dynamic snippets visibility, and an upgrade script (see [3])
set this class by default on them.

Later in 18.0 (after [2]), the class was changed to `s_dynamic_empty` in
the XML template, while on the JS side, the class used to toggle snippet
visibility was `o_dynamic_snippet_empty`. This class was also added to
snippets on destroy (before saving).

[B]- As a result, a dynamic snippet may end up with:

- `o_dynamic_empty` & `o_dynamic_snippet_empty`: for old (before 18.0) but
edited snippets.
- `o_dynamic_empty`: for old snippets never updated in edit mode on 18.0.
- `s_dynamic_empty` & `o_dynamic_snippet_empty`: for new snippets created
in 18.0.

Remark: the `s_dynamic_empty` class was introduced by mistake and does
not have any associated CSS

Since only `o_dynamic_snippet_empty` has `display: none` in CSS, the
interaction flow became inconsistent (starting from 18.2): snippets were
initially visible, then hidden if no content was found... which caused
the flickering behavior described above.

And because of [B], old snippets with the `o_dynamic_empty` class
will be visible by default in 18.0.

This commit restores the intended (and original) behavior:

- A dynamic snippet should be invisible by default,

- Then the interaction decides (based on actual content) whether the
snippet should be displayed.

[1]: https://github.com/odoo/odoo/commit/63def9c87305dd7773e0592a28fe19d0b63c0878
[2]: https://github.com/odoo/odoo/commit/76cf201e1fc356ad00b27bcdec408c54949df33b
[3]: https://github.com/odoo/upgrade/commit/af5821d9aeb75d09653fc33f14e98fae5f5ba906

opw-5354523

Forward-Port-Of: odoo/odoo#240036
Forward-Port-Of: odoo/odoo#238305