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

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

Since this change: https://github.com/odoo/odoo/pull/185674/commits/b663a6e3dbda6eda84e4a6b051acfc8511476cd3#diff-552aefb62246b1f4fe6a2607ec8f0a01773e53de2d68293266b38bc99c5cb56dR503 It introduces two bugs:
- Create a project A and project B, activate the top bar in both projects
    - Create a new custom embedded action in project A
    - Switch to project B (by changing the URL), the custom action of project A is present in project B
- In a project, create a new custom embedded action, refresh the page, the action is not visible nor available in the top bar.

It enters the if condition, and get the "lastAction", which may not contain the same "embedded_action_ids" than the current action (targeting another project or the same project if we just refreshed the page). It enters the condition because the path of the action is the same ("tasks") and no "active_id" is specified in the context of the action.

We then force the load of the action if the "lastAction" stored in the browser session had embedded actions, to be sure to get the latest embedded actions linked to the current action in case of any, and not keep the ones linked to "lastAction".

task-5269261

Forward-Port-Of: odoo/odoo#237695

**Steps to reproduce:**
- enable "packages" and "batch transfers" settings
- open wharehouse management/operation type
- select internal transfer
- check "automatic batch" and group by "contact"
- create two storable product with an on hand quantity of 10
- create a an internal transfer for the first product for a qty of 10
- mark it as to do
- do the same for the second product and make sure that it's the same 
contact
- open barcode and select batches
- select the last batch created
- scan WH-STOCK
- enter and confirm a quantity of 4 for each line
- click on put in pack
(at this step we can already see that the two new lines created are 
associated wit the second picking, even though it should be one line 
per picking)
- click on the +6 on each line and click on put in pack
- validate

**Current behavior:**
- a back order has been created for the first picking
- the first internal transfer has only delivered 4 units of the first 
product
- the second internal transfer has delivered 10 of the second product 
and 5 of the first product

**Expected behavior:**
both pickings should have delivered 10 of their product

**Cause of the issue:**
The lines created when clicking on "put in pack" for the first time
are both associated with the second picking because the line split:
https://github.com/odoo/enterprise/blob/898e3e47cfe3b86230da2b146960983d7ad144d0/stock_barcode/static/src/models/barcode_picking_model.js#L514
and the picking_id of the new line is set to the values provided by the
`_getNewLineDefaultValues` as the picking_id of the last selected `line`:
https://github.com/odoo/enterprise/blob/24b4e49dbe16cb8bd40170abfc089dd64c3f34dd/stock_barcode_picking_batch/static/src/models/barcode_picking_batch_model.js#L280-L281
rather than from the values of the initial line it is split from.

opw-4952964

Forward-Port-Of: odoo/enterprise#92891
Forward-Port-Of: odoo/enterprise#91378