Steps to see the issue:
- Add a shape to an image
- Remove it

=> Image element in the DOM still has some data related to the shape.
This commits adds a shared method to `ImageShapeOptionPlugin` to clean
shape-related data when we apply a shape, or remove it, the method
mirrors the behavior we had before the [html builder refactoring].

Also, commit [1] fixed the issue when the builder transfered shape or
hover related data to incompatible images, when replacing an image with
a shape/hover on it. However if these data attributes had already been
saved prior to that commit, it would stay there indefinitely. The same
could happen with hover effects attributes. Therefore, we add a
resource that we call before saving data to clean any stale image data.

Example of a CORS protected image: [2]

[1]: https://github.com/odoo-dev/odoo/commit/137a6d7e59e1d788745c3b796a14839e52a8c5bc
[2]: https://tinyjpg.com/images/social/website.jpg

[html builder refactoring]: github.com/odoo/odoo/9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2

task-5172640

Forward-Port-Of: odoo/odoo#263662
Forward-Port-Of: odoo/odoo#259226

Currently, an incorrect VAT format is used in the generated `FA3 XML`
for non-Polish partners, where the VAT number includes the country code.

**Steps to reproduce:**
- Install the `l10n_pl_edi` module and switch to a `PL Company`.
- Go to Settings and enable `Allow KSeF integration` (refer to [1]).
- Create and confirm an invoice for a customer (e.g., Azure Interior).
- Send the invoice using `by KSeF (e-Faktura)`.

**Observation:**
In the generated XML file, the `NrID` field contains the VAT number 
`with the country code` for non-Polish partners.

**Root Cause:**
At [2], `get_vat_number` sets the VAT number using `compact` from 
`stdnum.pl.nip`, which only works for Polish VAT numbers.

At [3], `get_vat_number` correctly formats Polish VAT numbers without 
the country code in the `if condition`. However, in the fallback (else) case, 
it returns the VAT number as it is, including the country code.

**Fix:**
This commit ensures that for non-Polish VAT numbers, the country code is 
removed before setting the `NrID` or `NrVatUE` values in the XML, 
aligning the format with KSeF requirements.

Ref: https://ksef.podatki.gov.pl/media/4u1bmhx4/information-sheet-on-the-fa-3-logical-structure.pdf (Page no.: 19)

[1]:
https://www.odoo.com/mail/message/1057847327

[2]:
https://github.com/odoo/odoo/blob/d73e5662a0af7c549008661f743ba5d51f765339/addons/l10n_pl_edi/models/account_move.py#L257

[3]:
https://github.com/odoo/odoo/blob/d73e5662a0af7c549008661f743ba5d51f765339/addons/l10n_pl_edi/data/fa3_template.xml#L67-L82

opw-6120118

Forward-Port-Of: odoo/odoo#263081

Steps to Reproduce:
---
1. Create a new project.
2. Convert it into a template.
3. Click on "Undo".
4. Try to convert the project into a template again.

Issue:
---
After undoing the template conversion, the project's original documents folder
remained archived while the template's documents folder stayed active. This
inconsistent state prevented subsequent template creation from the same project.

Current behaviour:
---
A UserError is raised: "You cannot duplicate document(s) in the Trash."

Expected behaviour:
---
Undoing the template conversion should properly restore the original project's
documents folder to active state and clean up the template's documents folder,
allowing template conversion again without document folder conflicts.

Fix:
---
- Archive original project's documents folder during template creation to
prevent mixed active/inactive states during copy operations
- Implement callback system to properly unarchive original project's
documents folder during undo

task-4916027

Forward-Port-Of: odoo/odoo#264429
Forward-Port-Of: odoo/odoo#223152

### Steps to reproduce:
- Download 'Sales', 'Accounting', and 'l10n_sa_edi' modules
- Settings > Accounting > Rounding Method > Enable global rounding
- Create sale order with 8 lines at 29.7 each with 15% taxes (triggers rounding precision issues)
- Create and confirm 100% downpayment invoice
- Deliver, then create final invoice with downpayment lines
- Call `_l10n_sa_get_prepaid_amount()` on final invoice
> Tax amount was calculated as 35.67 instead of correct 35.64

### Cause of Issue:
The prepaid amount calculation was summing pre-rounded `tax_amount_currency` values from individual downpayment lines (4.45 + 4.46 + 4.46... = 35.67), instead of summing unrounded `raw_tax_amount_currency` values (4.455 × 8 = 35.64) to calculate `tax_amount`. https://github.com/odoo/odoo/blob/27930ae41a5f03bd499983109de7f632472c3650/addons/l10n_sa_edi/models/account_edi_xml_ubl_21_zatca.py#L227-L240

This violates Odoo's [recent change](https://github.com/odoo/odoo/pull/180062) in `round_globally` pattern which states:
https://github.com/odoo/odoo/blob/8a88756bed194910bc5a47e93f0e29610dbeee1f/addons/account/models/account_tax.py#L2208

### Fix:
Ensure cumulative rounding errors are avoided and correct global rounding is applied.

opw-5881564

Forward-Port-Of: odoo/odoo#264713
Forward-Port-Of: odoo/odoo#261278

***Steps to reproduce*:**

- Install `l10n_co_reports` module.
- Create 2 vendor bills with taxes `0% EXEMPT` and `0.966% RteICA`.
- Navigate to Reports -> Colombian Statements -> Certificado de Retención en ICA
- Generate the PDF report.

***Observed behavior*:**

- An error is raised while generating the PDF: 
`AttributeError: 'AccountReportColumnData' object has no attribute 'get'`

***Cause*:**

After commit [1](https://github.com/odoo-dev/enterprise/commit/b92dc397bef029472a40223f51b611cdf5b631dc#diff-e97f74c63a6257470e69eb8122c12d0ce4afa5bc6013176bb69e702849575123) all report lines, columns, and annotations were converted
from dictionaries to custom objects (e.g., AccountReportColumnData). However,
the function `_get_report_values` still uses .get() to access values, which is only valid 
for dictionaries. Calling .get() on these objects raises an error.

***Fix*:**

- Replace the `get()` method usage with `column.name` format to access 
  values from `AccountReportColumnData ' properly.
- This ensures compatibility with the new structured column data format introduced in v19.2.

opw-6205984

Forward-Port-Of: odoo/enterprise#116902

Currently, a CSS rule forces the form container width to 1px to ensure that the nested list view can correctly compute its size.

See:

```scss
.o_form_view.o_xxl_form_view {
    .o_form_view_container {
        width: 1px; /* List view needs a width value to recompute the size correctly */
    }
}
```

However, since the Knowledge editor is implemented as a form view, this rule also affects Knowledge. When zooming out, the `o_xxl_form_view` class is added to the form view container, causing the rule to apply. If an article is printed while this class is present, it is constrained to an extremely narrow column, making it unreadable.

Steps to reproduce:
1. Open an article in Knowledge
2. Zoom out using `Ctrl` + `-`
3. Open the kebab menu and select "Export"

=> The article is rendered in a very narrow column.

To address this issue, we override this rule specifically for Knowledge. With this change, articles are now rendered correctly when printed or exported as PDF.

Task-5999878

Forward-Port-Of: odoo/enterprise#103259

### Steps to reproduce:
- Download 'Sales', 'Accounting', and 'l10n_sa_edi' modules
- Settings > Accounting > Rounding Method > Enable global rounding
- Create sale order with 8 lines at 29.7 each with 15% taxes (triggers rounding precision issues)
- Create and confirm 100% downpayment invoice
- Deliver, then create final invoice with downpayment lines
- Call `_l10n_sa_get_prepaid_amount()` on final invoice
> Tax amount was calculated as 35.67 instead of correct 35.64

### Cause of Issue:
The prepaid amount calculation was summing pre-rounded `tax_amount_currency` values from individual downpayment lines (4.45 + 4.46 + 4.46... = 35.67), instead of summing unrounded `raw_tax_amount_currency` values (4.455 × 8 = 35.64) to calculate `tax_amount`. https://github.com/odoo/odoo/blob/27930ae41a5f03bd499983109de7f632472c3650/addons/l10n_sa_edi/models/account_edi_xml_ubl_21_zatca.py#L227-L240

This violates Odoo's [recent change](https://github.com/odoo/odoo/pull/180062) in `round_globally` pattern which states:
https://github.com/odoo/odoo/blob/8a88756bed194910bc5a47e93f0e29610dbeee1f/addons/account/models/account_tax.py#L2208

### Fix:
Ensure cumulative rounding errors are avoided and correct global rounding is applied.

opw-5881564

Forward-Port-Of: odoo/odoo#264713
Forward-Port-Of: odoo/odoo#261278

Currently, an incorrect VAT format is used in the generated `FA3 XML`
for non-Polish partners, where the VAT number includes the country code.

**Steps to reproduce:**
- Install the `l10n_pl_edi` module and switch to a `PL Company`.
- Go to Settings and enable `Allow KSeF integration` (refer to [1]).
- Create and confirm an invoice for a customer (e.g., Azure Interior).
- Send the invoice using `by KSeF (e-Faktura)`.

**Observation:**
In the generated XML file, the `NrID` field contains the VAT number 
`with the country code` for non-Polish partners.

**Root Cause:**
At [2], `get_vat_number` sets the VAT number using `compact` from 
`stdnum.pl.nip`, which only works for Polish VAT numbers.

At [3], `get_vat_number` correctly formats Polish VAT numbers without 
the country code in the `if condition`. However, in the fallback (else) case, 
it returns the VAT number as it is, including the country code.

**Fix:**
This commit ensures that for non-Polish VAT numbers, the country code is 
removed before setting the `NrID` or `NrVatUE` values in the XML, 
aligning the format with KSeF requirements.

Ref: https://ksef.podatki.gov.pl/media/4u1bmhx4/information-sheet-on-the-fa-3-logical-structure.pdf (Page no.: 19)

[1]:
https://www.odoo.com/mail/message/1057847327

[2]:
https://github.com/odoo/odoo/blob/d73e5662a0af7c549008661f743ba5d51f765339/addons/l10n_pl_edi/models/account_move.py#L257

[3]:
https://github.com/odoo/odoo/blob/d73e5662a0af7c549008661f743ba5d51f765339/addons/l10n_pl_edi/data/fa3_template.xml#L67-L82

opw-6120118

Forward-Port-Of: odoo/odoo#263081

Steps to Reproduce:
---
1. Create a new project.
2. Convert it into a template.
3. Click on "Undo".
4. Try to convert the project into a template again.

Issue:
---
After undoing the template conversion, the project's original documents folder
remained archived while the template's documents folder stayed active. This
inconsistent state prevented subsequent template creation from the same project.

Current behaviour:
---
A UserError is raised: "You cannot duplicate document(s) in the Trash."

Expected behaviour:
---
Undoing the template conversion should properly restore the original project's
documents folder to active state and clean up the template's documents folder,
allowing template conversion again without document folder conflicts.

Fix:
---
- Archive original project's documents folder during template creation to
prevent mixed active/inactive states during copy operations
- Implement callback system to properly unarchive original project's
documents folder during undo

task-4916027

Forward-Port-Of: odoo/odoo#264429
Forward-Port-Of: odoo/odoo#223152

Currently, a CSS rule forces the form container width to 1px to ensure that the nested list view can correctly compute its size.

See:

```scss
.o_form_view.o_xxl_form_view {
    .o_form_view_container {
        width: 1px; /* List view needs a width value to recompute the size correctly */
    }
}
```

However, since the Knowledge editor is implemented as a form view, this rule also affects Knowledge. When zooming out, the `o_xxl_form_view` class is added to the form view container, causing the rule to apply. If an article is printed while this class is present, it is constrained to an extremely narrow column, making it unreadable.

Steps to reproduce:
1. Open an article in Knowledge
2. Zoom out using `Ctrl` + `-`
3. Open the kebab menu and select "Export"

=> The article is rendered in a very narrow column.

To address this issue, we override this rule specifically for Knowledge. With this change, articles are now rendered correctly when printed or exported as PDF.

Task-5999878

Forward-Port-Of: odoo/enterprise#103259

### Steps to reproduce:
- Download 'Sales', 'Accounting', and 'l10n_sa_edi' modules
- Settings > Accounting > Rounding Method > Enable global rounding
- Create sale order with 8 lines at 29.7 each with 15% taxes (triggers rounding precision issues)
- Create and confirm 100% downpayment invoice
- Deliver, then create final invoice with downpayment lines
- Call `_l10n_sa_get_prepaid_amount()` on final invoice
> Tax amount was calculated as 35.67 instead of correct 35.64

### Cause of Issue:
The prepaid amount calculation was summing pre-rounded `tax_amount_currency` values from individual downpayment lines (4.45 + 4.46 + 4.46... = 35.67), instead of summing unrounded `raw_tax_amount_currency` values (4.455 × 8 = 35.64) to calculate `tax_amount`. https://github.com/odoo/odoo/blob/27930ae41a5f03bd499983109de7f632472c3650/addons/l10n_sa_edi/models/account_edi_xml_ubl_21_zatca.py#L227-L240

This violates Odoo's [recent change](https://github.com/odoo/odoo/pull/180062) in `round_globally` pattern which states:
https://github.com/odoo/odoo/blob/8a88756bed194910bc5a47e93f0e29610dbeee1f/addons/account/models/account_tax.py#L2208

### Fix:
Ensure cumulative rounding errors are avoided and correct global rounding is applied.

opw-5881564

Forward-Port-Of: odoo/odoo#264713
Forward-Port-Of: odoo/odoo#261278

## Issue
When making a request for quotation for a subcontracted product and returning the delivery "for exchange", the new incoming delivery does not have the correct destination. Instead of having the stock of the user, the destination of the new incoming delivery is the same as its source: the subcontracting location.

<img width="1254" height="257" alt="5479900" src="https://github.com/user-attachments/assets/c7e6d392-8328-4a03-a71e-466e768f448b" />

## Steps to reproduce
1. Install MRP Subcontracting (`mrp_subcontracting`) and Purchase (`purchase`)
2. In Settings, enable *Subcontracting*
3. Create a Product P and a subcontracting BoM with Subcontractor S
4. Create a Request for Quotation
    - Vendor: Subcontractor S
    - Product: Product P (any quantity > 0)
5. Confirm the RFQ, receive the PO, validate the picking
6. On the validated picking, click *Return*, set the quantity of products to return, and click *Return for Exchange*
    - This creates two new pickings, one to return the product(s) we received, and one to receive new products
7. Validate the two new pickings
8. **In Inventory > Reporting > Moves History, the very last `stock.move.line` has the same location in the *From* (`location_id`) and the *To* (`location_dest_id`) columns**

## Cause
The `location_dest_id` of the new `stock.move` is updated in `StockReturnPickingLine._prepare_move_default_values`.

https://github.com/odoo/odoo/blob/fb534f1eadcb8ef74e2ee6fd5b68872dddb978e3/addons/mrp_subcontracting/wizard/stock_picking_return.py#L20-L25

The condition added by https://github.com/odoo/odoo/commit/5404b426aac9 sets the destination of all returned subcontracted moves to the subcontractor location. This is incorrect when using "return for exchange", as in this case, the return move is directed towards the user's stock. In fact, when using "return for exchange", the following pickings are created:

| id | name         | return_id |   |
|:--:|--------------|:---------:|---|
| 1  | WH/IN/00001  |           | Initial RFQ delivery |
| 2  | WH/OUT/00001 |     1     | Return of the initial RFQ delivery |
| 3  | WH/IN/00002  |     2     | New products delivery to replace the initial delivery. The stock.move.line of this stock.picking has a wrong `location_dest_id` |

## Fix
In the context of return for exchanges, the returned item must be directed to the *Subcontracting Location* while the new item must be directed to   the *Stock*. In the `_prepare_move_default_values`, we should only set   the `location_dest_it` to the subcontractor location for outgoing pickings.

opw-5479900

Forward-Port-Of: odoo/odoo#264798
Forward-Port-Of: odoo/odoo#245905

There is no need to do a query to get a random foreign state. This search can be performed many times during imports.

While the query is generally not reading a lot of data, it is still doing a seq scan because of the ORDER BY, while the query can be avoided completely.

```sql
EXPLAIN ANALYZE
  SELECT "res_country_state"."id"
    FROM "res_country_state"
   WHERE "res_country_state"."code" NOT IN ('IN')
ORDER BY "res_country_state"."code", "res_country_state"."id"
   LIMIT 1;
                                                          QUERY PLAN
------------------------------------------------------------------------------------------------------------------------------
 Limit  (cost=84.93..84.94 rows=1 width=8) (actual time=0.450..0.450 rows=1 loops=1)
   ->  Sort  (cost=84.93..90.49 rows=2224 width=8) (actual time=0.449..0.449 rows=1 loops=1)
         Sort Key: code, id
         Sort Method: top-N heapsort  Memory: 25kB
         ->  Seq Scan on res_country_state  (cost=0.00..73.81 rows=2224 width=8) (actual time=0.012..0.281 rows=2223 loops=1)
               Filter: ((code)::text <> 'IN'::text)
               Rows Removed by Filter: 2
 Planning Time: 0.075 ms
 Execution Time: 0.462 ms
```

This can be worse if when the table is not in the buffer.

Forward-Port-Of: odoo/odoo#265007

[*]: html_builder

Issue:
When viewing a blog post, the "Next Post" section allows editing the cover image, title, and subtitle of another post. Editing content that belongs to a different post from within the current one is incorrect.

Steps to reproduce:
  * Open a blog post that has a "Next Post" section visible.
  * Enter edit mode.
  * Try to edit the cover image, title, or subtitle of the next post.
  * These elements can be interacted with even though they should not be
    editable.

Fix:
Make the "Next Post" section fully non-editable. The title and subtitle were already handled via content_not_editable_selectors, but the cover image could still activate builder options, allowing it to be replaced.

Introduce a new `not_activable_element_selectors` resource in the `BuilderOptionsPlugin` so that plugins can declare elements that should not trigger the builder overlay when clicked. Updated the builder to retrieve this selector list from plugin resources instead of using a hardcoded value.

task-5435878

Forward-Port-Of: odoo/odoo#249815

Currently, a CSS rule forces the form container width to 1px to ensure that the nested list view can correctly compute its size.

See:

```scss
.o_form_view.o_xxl_form_view {
    .o_form_view_container {
        width: 1px; /* List view needs a width value to recompute the size correctly */
    }
}
```

However, since the Knowledge editor is implemented as a form view, this rule also affects Knowledge. When zooming out, the `o_xxl_form_view` class is added to the form view container, causing the rule to apply. If an article is printed while this class is present, it is constrained to an extremely narrow column, making it unreadable.

Steps to reproduce:
1. Open an article in Knowledge
2. Zoom out using `Ctrl` + `-`
3. Open the kebab menu and select "Export"

=> The article is rendered in a very narrow column.

To address this issue, we override this rule specifically for Knowledge. With this change, articles are now rendered correctly when printed or exported as PDF.

Task-5999878

Forward-Port-Of: odoo/enterprise#103259

Commit 28b840b introduced logic to include `freight_costs` in the customs document generated bySendcloud. It introduced 2 new issues as a result:

1. When creating backorders, the `freight_costs` are not divided but instead propagated to all of the pickings.
2. When there is no SO, we were taking the total value of all delivered goods, which doesn't make much sense considering the `freight_costs` field should be the cost of the delivery itself.

Solution
-----
For the first problem, there are a couple things to keep in mind:
- the total `freight_costs` declared to the customs entity should be the amount invoiced to the customer
- products can be added and removed from the picking after the SO has been confirmed
- actual delivery cost can change between invoice date and actual delivery date
- picking can be split into multiple packages at the user's discretion

Considering all of the above, we will simply forward the invoiced amount with the first confirmed picking and none of the backorders.

-----
Ticket:
opw-6013387

Forward-Port-Of: odoo/enterprise#116639
Forward-Port-Of: odoo/enterprise#111304

**Problem:**
When a project analytic budget is revised, the project update description shows an inflated total budget — the sum of both the original and the revised amounts — instead of reflecting only the active (confirmed) revision.

**Steps to reproduce:**
1. Create a project with an analytic account
2. Create an analytic budget of $10,000 and confirm it
3. Create a revision of that budget for $15,000 and confirm it
4. Create a new project update
5. The update shows "$25,000" as the total budget instead of "$15,000"

**Current behavior:**
The project update displays the sum of all budget revisions ($25,000), regardless of their state.

**Expected behavior:**
Only the active confirmed budget ($15,000) should be used.

**Cause of the issue:**
`_compute_budget` queries all `budget.line` records matching the project's analytic account without filtering by the parent `budget.analytic` state. When a budget is revised, the original transitions to state `revised` while the new one becomes `confirmed`. Because `_compute_budget` has no state filter, it sums both, producing an inflated `total_budget_amount`. This field is then used in the project update template to compute the displayed budget total and percentage. By contrast, `_get_budget_items` — used for the detail rows — already applies `state in ['confirmed', 'done']`, so the two methods were inconsistent.

**Fix:**
Applying the same state filter to `_compute_budget` as already present in `_get_budget_items` ensures both methods draw from the same set of active budgets, keeping the project update totals consistent with the budget detail rows.

opw-6128855

Forward-Port-Of: odoo/enterprise#116670
Forward-Port-Of: odoo/enterprise#115285

Currently, a CSS rule forces the form container width to 1px to ensure that the nested list view can correctly compute its size.

See:

```scss
.o_form_view.o_xxl_form_view {
    .o_form_view_container {
        width: 1px; /* List view needs a width value to recompute the size correctly */
    }
}
```

However, since the Knowledge editor is implemented as a form view, this rule also affects Knowledge. When zooming out, the `o_xxl_form_view` class is added to the form view container, causing the rule to apply. If an article is printed while this class is present, it is constrained to an extremely narrow column, making it unreadable.

Steps to reproduce:
1. Open an article in Knowledge
2. Zoom out using `Ctrl` + `-`
3. Open the kebab menu and select "Export"

=> The article is rendered in a very narrow column.

To address this issue, we override this rule specifically for Knowledge. With this change, articles are now rendered correctly when printed or exported as PDF.

Task-5999878

Forward-Port-Of: odoo/enterprise#103259

When a sale order containing a product with a custom (free text) attribute was settled in POS, the order line displayed the placeholder attribute value name (e.g. "Custom") instead of the actual text entered by the customer.

Steps to reproduce:
-------------------
* Create a product with a free text attribute (create_variant='no_variant', is_custom=True)
* Go to the website's shop (works best in a new private tab)
* Fill the free text attribute and add the product to the cart
* Click on checkout
* In POS, open Quotation/Order and settle the order

> Observation:
the order line shows "Custom" instead of the text

Why the fix:
------------
`SaleOrderLine._load_pos_data_fields` was not exposing `product_no_variant_attribute_value_ids` nor `product_custom_attribute_value_ids`, so the JS `settleSO` function received no attribute data on the `line` object. As a result, the new POS order line was created with empty `attribute_value_ids` and `custom_attribute_value_ids`, leaving `constructFullProductName` unable to find the custom text.

The fix adds both fields to `_load_pos_data_fields` and updates `settleSO` to use them when building the new POS order line. The dynamic fetch path (`_getSaleOrder`) is also updated to explicitly read the `product.attribute.custom.value` records so the data is available for orders loaded at runtime.

opw-5958678

Forward-Port-Of: odoo/odoo#263913
Forward-Port-Of: odoo/odoo#251993

**Problem:**
When a project analytic budget is revised, the project update description shows an inflated total budget — the sum of both the original and the revised amounts — instead of reflecting only the active (confirmed) revision.

**Steps to reproduce:**
1. Create a project with an analytic account
2. Create an analytic budget of $10,000 and confirm it
3. Create a revision of that budget for $15,000 and confirm it
4. Create a new project update
5. The update shows "$25,000" as the total budget instead of "$15,000"

**Current behavior:**
The project update displays the sum of all budget revisions ($25,000), regardless of their state.

**Expected behavior:**
Only the active confirmed budget ($15,000) should be used.

**Cause of the issue:**
`_compute_budget` queries all `budget.line` records matching the project's analytic account without filtering by the parent `budget.analytic` state. When a budget is revised, the original transitions to state `revised` while the new one becomes `confirmed`. Because `_compute_budget` has no state filter, it sums both, producing an inflated `total_budget_amount`. This field is then used in the project update template to compute the displayed budget total and percentage. By contrast, `_get_budget_items` — used for the detail rows — already applies `state in ['confirmed', 'done']`, so the two methods were inconsistent.

**Fix:**
Applying the same state filter to `_compute_budget` as already present in `_get_budget_items` ensures both methods draw from the same set of active budgets, keeping the project update totals consistent with the budget detail rows.

opw-6128855

Forward-Port-Of: odoo/enterprise#116670
Forward-Port-Of: odoo/enterprise#115285

When an embedded action is created from a server action, its name is just stored as is. When using these actions e.g. in the Documents top bar, there is already a "hack" to copy the name of the server action to the embedded action in each active language.

This has a few issues:
- When a language is activated after the embedded action creation, the name of the server action is not copied to the embedded action, resulting in an untranslated name.
- When the name of the server action is changed, the name of the embedded action is not updated, resulting in an outdated and possibly untranslated name.

The workaround is to disable/enable the action now, but it's not very user-friendly and can be easily forgotten.

To fix this, we can simply delegate the display name of the embedded action to the linked server action. This way, the name of the embedded action will always be up to date and correctly translated.

Related: https://github.com/odoo/enterprise/pull/116369

Forward-Port-Of: odoo/odoo#262981

### Steps to reproduce:

- In the settings enable dropshipping
- Create a storable product P, enable the dropshipping and set a vendor
- Create and confirm a sale order for a field service
- Open the related task > Products > Add 1 unit of P
- Go back to the sale order > an RFQ has been created
#### > The delivered quantity of P is set to 1

### Cause of the issue:

Since 2361368acfe7fecbffde2ca26392eb89aecdc9e1 the `_inverse_fsm_quantity` method manually adapts the delivered quantity based on the fact that the `product.service_type` is `manual` rather than the `qty_delivered_method` of the line or future line is. In particular, because these lines: https://github.com/odoo/enterprise/blob/8f4fe902cb71c49bdb3caf9915f9a5abfe6f237f/industry_fsm_sale/models/product_product.py#L82-L83
provide a value of the `qty_delivered` to the created purchase order line and since the `qty_delivered_method` is a precomputed field: https://github.com/odoo/odoo/blob/fdfd9851393ff82a265997478886bcad6da357d0/addons/sale/models/sale_order_line.py#L225-L237
The fact that the purchase order line will be created with a `stock_move` `qty_delivered_method` and that the generated PO does not generate any move prior to confirmation will not trigger the dependency of the `qty_delivered` to retrigger a computation of the `delivered_qty` of the product which is suppose to be based on stock pickings: https://github.com/odoo/odoo/blob/fdfd9851393ff82a265997478886bcad6da357d0/addons/sale/models/sale_order_line.py#L871-L876 https://github.com/odoo/odoo/blob/fdfd9851393ff82a265997478886bcad6da357d0/addons/sale_stock/models/sale_order_line.py#L193-L198
Leaving the created sol with a delivered quantity of 1 prior to confirmation of the PO (which will generate move_ids related to the sol and trigger the compute).

Fix:

The changes of 2361368acfe7fecbffde2ca26392eb89aecdc9e1 regarding the `_inverse_fsm_quantity` appears unjustified with respect to the purpose of the fix. In addition, the `qty_delivered` and changes are already expected to be properly computed when the `qty_delivered_method` is not manual, particularly since the '`manual'` `service_type` is actually the default `service_type` corresponding to any 'consu' product and looks unrelated by any mean to the `delivered_qty` computation: https://github.com/odoo/odoo/blob/fdfd9851393ff82a265997478886bcad6da357d0/addons/sale/models/product_template.py#L165-L167

opw-6104326

Forward-Port-Of: odoo/enterprise#115760

## Issue 1:

Backport of 7654c558c4d517807884b0a82323dd160feeda2a

For Colombia, Envia expects the municipality/DANE-style code in the address payload, not the raw postal code.
    
When `l10n_co_edi` was not installed, the Envia integration fell back to the partner zip code and padded it locally before sending it as both `postalCode` and `city`. This produced incorrect values such as turning the Ibagué zip code `730001` into `73000100`, while Envia geocodes resolves that zip code to `73001000`.
    
Use Envia geocodes to resolve the Colombia zip fallback and retrieve the `stat_8digit` code expected by Envia instead of deriving it locally.

## Issue 2:

### Steps to reproduce:

  - Install delivery_envia
  - Website > Configuration > eCommerce > Delivery Methods > Envia
  - Enable the delivery method, sync the carrier and Publish it
  - With a portal user > Shop > Add any product to your cart > Checkout
  - Register an address a valid 'Chile' address and confirm say:
      'street and Number': Avenida Providencia 1432, Depto 402
      'city': Santiago 'zip': 8320000
      'country': Chile 'state': Metropolitana
  > Envia Error: Invalid Option - String is too long at #->properties:destination
  
### Cause of the issue:
  
The problem is caused by the fact that Envia's api expects a 2-3 digits to represent state codes: https://docs.envia.com/reference/state-by-code
The mapping from Odoo's code state representation to envia's one is expected ot be performed by this mapping:
https://github.com/odoo/enterprise/blob/75cba6d5a88ebc4e0f35040a173ac1c443638daf/delivery_envia/models/envia_request.py#L27-L43
when the address is converted here:
  https://github.com/odoo/enterprise/blob/75cba6d5a88ebc4e0f35040a173ac1c443638daf/delivery_envia/models/envia_request.py#L535-L542
That being said, the `Chile`'s code states of have been changed in 6694a3942c58ff1a56c9e4b36edbe126dd1e66f8 to match the official Iso but not in the Envia's mapping leading a failling match keeping the 4 charracter long `CL-RM` of the `Metropolitan` state provided in to the Envia's api as address data.

opw-6083181
opw-6210007

Forward-Port-Of: odoo/enterprise#117414

Steps to produce:
---
- Install website_sale module.
- Enable `Comparison Price` from settings.
- Create a product with sales price = 25 and compare price = 25.
- Go to the shop page and search for the product.

Issue:
---
- The strikethrough appears on the compare price (25) even when the compare price equals the sales price.
- The strikethrough should only appear when the compare price is strictly greater than the sales price.

Root cause:
---
- In `_search_render_results_prices` [1], the condition only checks for the presence of `compare_list_price` in `combination_info`, without verifying that it is actually greater than the sales price. This causes the strikethrough to render even when both prices are equal.

Solution:
---
- Added a strict greater-than check on compare price against the sales price, aligning with the existing behavior already implemented for the product page [2].

Before:
---
<img width="537" height="98" alt="image" src="https://github.com/user-attachments/assets/a1524f0f-4a59-4daf-ac7d-834604710492" />

After:
---
<img width="538" height="95" alt="image" src="https://github.com/user-attachments/assets/1e32269b-13c0-469b-9d1f-e6d6ced97fdd" />


[1]https://github.com/odoo/odoo/blob/4ca059731f97d0f9bce4863cf195fd68a755717e/addons/website_sale/models/product_template.py#L831-L834
[2]https://github.com/odoo/odoo/blob/4ca059731f97d0f9bce4863cf195fd68a755717e/addons/website_sale/views/templates.xml#L1340-L1346

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

Forward-Port-Of: odoo/odoo#264912
Forward-Port-Of: odoo/odoo#262434

Before this commit, there was no way to tell the ColorPicker to not use the DEFAULT_THEME_COLOR_VARS (ie classes of the form o-color-[n] with n some integer)

Those colors are a bit special (see full discussion on the opw)

    Their existence is described in module web
    Their CSS definition is implemented in module html_editor
    Reports don't use them at all We probably don't want reports' style
    to be influenced by the presence or lack thereof of the html_editor
    module, which was originally made to customize the interface.

Those architecture issues should be solved downstream in master, but they are practically endemic in Odoo.

This commit addresses the fact that Studio's report editor should not allow those colors as possible customization by offering the components and plugins in the chain a props to disable them.

After this commit (and more broadly the PR bundle), the default theme colors are not available in studio's report editor.

see odoo/odoo#251446
backport of https://github.com/odoo/enterprise/pull/109206
opw-6167143


community: https://github.com/odoo/odoo/pull/264917

Forward-Port-Of: odoo/enterprise#117555

## Issue 1:

Backport of 7654c558c4d517807884b0a82323dd160feeda2a

For Colombia, Envia expects the municipality/DANE-style code in the address payload, not the raw postal code.
    
When `l10n_co_edi` was not installed, the Envia integration fell back to the partner zip code and padded it locally before sending it as both `postalCode` and `city`. This produced incorrect values such as turning the Ibagué zip code `730001` into `73000100`, while Envia geocodes resolves that zip code to `73001000`.
    
Use Envia geocodes to resolve the Colombia zip fallback and retrieve the `stat_8digit` code expected by Envia instead of deriving it locally.

## Issue 2:

### Steps to reproduce:

  - Install delivery_envia
  - Website > Configuration > eCommerce > Delivery Methods > Envia
  - Enable the delivery method, sync the carrier and Publish it
  - With a portal user > Shop > Add any product to your cart > Checkout
  - Register an address a valid 'Chile' address and confirm say:
      'street and Number': Avenida Providencia 1432, Depto 402
      'city': Santiago 'zip': 8320000
      'country': Chile 'state': Metropolitana
  > Envia Error: Invalid Option - String is too long at #->properties:destination
  
### Cause of the issue:
  
The problem is caused by the fact that Envia's api expects a 2-3 digits to represent state codes: https://docs.envia.com/reference/state-by-code
The mapping from Odoo's code state representation to envia's one is expected ot be performed by this mapping:
https://github.com/odoo/enterprise/blob/75cba6d5a88ebc4e0f35040a173ac1c443638daf/delivery_envia/models/envia_request.py#L27-L43
when the address is converted here:
  https://github.com/odoo/enterprise/blob/75cba6d5a88ebc4e0f35040a173ac1c443638daf/delivery_envia/models/envia_request.py#L535-L542
That being said, the `Chile`'s code states of have been changed in 6694a3942c58ff1a56c9e4b36edbe126dd1e66f8 to match the official Iso but not in the Envia's mapping leading a failling match keeping the 4 charracter long `CL-RM` of the `Metropolitan` state provided in to the Envia's api as address data.

opw-6083181
opw-6210007

Forward-Port-Of: odoo/enterprise#117414

This commit removes the holiday pay recovery wizard and replaces it with salary rules
applied automatically in December payslips and in termination fees payslips for
joint committee 200.

The regularization now computes the missing simple and double holiday pay when the
amount paid during the year is lower than the amount due, both at year-end and at
contract end. If the amount already paid is higher, no correction is applied.

The implementation:

- computes remuneration N-1 including fictive salary for assimilated absences
- applies a different N-1 remuneration depending on the context:
        - departure attest: includes 13th month salary
        - December settlement: excludes 13th month salary
- computes simple holiday pay due as 7.67% of remuneration N-1
- computes simple holiday pay recovery as max(due - received, 0)
- computes double holiday pay due based on the higher of:
        - 7.67% of remuneration N-1
        - the wage of the month when the employee reached half of their legal holidays
- computes double holiday pay recovery as max(due - received, 0)
- splits double holiday pay into base and complementary components
- uses the Partena-based logic to determine the main holiday month

Users can still manually adjust the result directly on payslip lines when needed.

Related PRs:
upgrade: [github.com/odoo/upgrade/pull/9628](http://github.com/odoo/upgrade/pull/9628)

task-5429973

Two bugs stem from the payrun "step bubble" bar (Employees → Time [→ Attendance] → Payslips):

1. When a payrun not containing attendance-tracked employees is opened first and I change one of the employee's tracking method to attendance, going back via breadcrumb I'd see that the Attendance bubble incorrectly appears for the latter. The root cause is that cachePayRunSteps is a Map iterated in insertion order: "attendance" is appended after "payslip" the first time it is encountered, so it always renders last regardless of the server-defined canonical order. Fixed by turning it into an array overridden at every data fetch.

2. When navigating back to the payrun list via breadcrumb after changing the last of an employee's work_entry_source (e.g. removing the last attendance-tracked employee from a payrun), the bubble still shows the previous state. Fixed by marking the payrun as fresh when following specific flow, preventing the reload of the bubbles using instead the previously cached ones.

task-5959087

Forward-Port-Of: odoo/enterprise#117590

Currently, a CSS rule forces the form container width to 1px to ensure that the nested list view can correctly compute its size.

See:

```scss
.o_form_view.o_xxl_form_view {
    .o_form_view_container {
        width: 1px; /* List view needs a width value to recompute the size correctly */
    }
}
```

However, since the Knowledge editor is implemented as a form view, this rule also affects Knowledge. When zooming out, the `o_xxl_form_view` class is added to the form view container, causing the rule to apply. If an article is printed while this class is present, it is constrained to an extremely narrow column, making it unreadable.

Steps to reproduce:
1. Open an article in Knowledge
2. Zoom out using `Ctrl` + `-`
3. Open the kebab menu and select "Export"

=> The article is rendered in a very narrow column.

To address this issue, we override this rule specifically for Knowledge. With this change, articles are now rendered correctly when printed or exported as PDF.

Task-5999878

Forward-Port-Of: odoo/enterprise#103259

Currently when user adds adds quantity in barcode using lots it leads to incorrect sale order quantities.

## Steps to replicate:
- Install Sales and Barcode (no demo data).
- Enable Lots & Serial Numbers in settings.
- Create Test Product with Tracking by Lots.
- Go to Inventory > Products>Lots & Serial Numbers and create 3 lots for the product.
- Update each lot’s on-hand quantity to 10 from the product page.
- Create and confirm a Sales Order for the product (lines: qty 3 and 2 units).
- Open the delivery in the Barcode app:
   - Scan lot 2 > increase qty to 3 using +1 button
   - Scan lot 3 > increase qty to 2 using +1 button
- Validate and go to the sale order.

## Observed Behavior:
The sale order delivered quantities are flipped and a backorder is created even though the quantity for the product is satisfied.

## Root cause:
The issue occurs because when a sales order is confirmed, the system defaults to
 using lot 1 on the delivery receipt. When a user scans lot 2, the `_processBarcode` function is triggered, which calls `_findLine` at [1] to select the appropriate line on the receipt.

As the loop in `_findLine` iterates through `pageLines` with values like: 
```
[{display_name: "Test product", quantity: 3, lot_id: { name: 'lot1' }}, 
{display_name: "Test product", quantity: 2, lot_id: { name: 'lot1' }}]
```

During the first iteration, `foundLine` is set at [2] for the line with quantity 3 . Since the subsequent if condition is not satisfied, the loop hits the continue block at [3].
On the next iteration, the line with quantity 2 causes `foundLine` to be overwritten at [2], and the continue block is executed again at [3].

This results in the line with quantity 2 being selected as the line to update at the end of the function.

When the user manually increases the quantity to 3, the line that originally required quantity 2 is updated and fulfilled.
Later, when lot 3 is scanned, the line that required quantity 3 is selected for update, and manually increasing the quantity to 2 before validating the order leads to a backorder and causes the delivered quantities to be flipped.

[1]:
https://github.com/odoo/enterprise/blob/81eaeb4b18d849c644160234def6c69013591abe/stock_barcode/static/src/models/barcode_model.js#L1335-L1337 [2]:
https://github.com/odoo/enterprise/blob/81eaeb4b18d849c644160234def6c69013591abe/stock_barcode/static/src/models/barcode_model.js#L1690-L1699 [3]:
https://github.com/odoo/enterprise/blob/81eaeb4b18d849c644160234def6c69013591abe/stock_barcode/static/src/models/barcode_model.js#L1727-L1729

## Solution:
Avoid grouping lines from different moves unless using batch transfers. This ensures that backorders are not created when the barcode lines are fulfilled.

opw-5423943

Steps to produce:
---
- Install `website_sale`, `l10n_ca` & `accountant` modules with demo data.
- Switch to a `Canadian (CA) company.`
- Go to Settings and enable` Discounts, Loyalty & Gift Cards`.
- Go to` Website > eCommerce > Loyalty > Discount & Loyalty.`
- Create a new program > Set Program Type to Discount Code > Under Conditional Rules, set Minimum Purchase to 0 > Under Rewards, choose Discount on Order.
- Go to `website > configuration > websites` > Create a new website for the CA company > Set it as default (first in sequence).
- Create new product > Set Sales Taxes to` 14.975% GST + QST` > Publish the product.
- Open the website in an incognito window > Add the product to the cart > Apply the discount code.
- In the main tab > Go to Website > eCommerce > Orders > Open the corresponding order > In the Other Info tab, change the fiscal position to Quebec (QC) > Click to update taxes.

Issue:
---
- The tax on the discount line is split into: 14.975% GST + QST & 9.975% QST.

Root cause:
---
- When a discount is applied in the cart, the discount line initially carries split taxes: 5% GST and 9.975% QST.
- After changing the fiscal position to Quebec (QC), the system replaces 5% GST with 14.975% GST + QST because 5% GST is present in replace of 14.975% GST. so at [1] it replaces 5% GST with 14.975% GST and do nothing for 9.975% QST.
- In 17.0, the discount line directly uses 14.975% GST + QST (no tax splitting), so this issue does not occur.
- In 18.0, at [2], taxes are explicitly split and added to the base line, and the same split taxes are reused during grouping. This leads to multiple taxes being displayed on the sale order line.

Fix:
---
- Avoid splitting taxes on the discount line in the sale order.
- Keep the original tax structure intact to prevent duplication after fiscal position changes.

[1]https://github.com/odoo/odoo/blob/c6d9fa5873eb759846e9be5b66eedb8b00c5ac11/addons/account/models/partner.py#L151-L156
[2]https://github.com/odoo/odoo/blob/c6d9fa5873eb759846e9be5b66eedb8b00c5ac11/addons/sale_loyalty/models/sale_order.py#L296

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

### Issue:
When a user with "Bookkeeper" (Accounting) rights tries to reset a Bill to draft, the process is blocked by the following UserError: "You cannot delete this entry, as it has already consumed a sequence number and is not the last one in the chain. You should probably revert it instead."

This occurs specifically when another journal entry has been created and posted in the deferred move's journal after the deferred entries, blocking the sequence for non-manager users

However, a Bookkeeper should technically be allowed to reset these moves, as they can manually reset them to draft, clear the name, and delete them
You can refer to the comment on the function `_unlink_forbid_parts_of_chain()`

### Cause:
`self.deferred_move_ids._unlink_or_reverse()` attempts to unlink the deferred moves
During unlinking, the system performs a sequence integrity check
For non-manager users, this check prevents the deletion of moves that are not the last ones in the journal's sequence
https://github.com/odoo/odoo/blob/1497cd0a590e0a9089d6c041b57930aaecba42ea/addons/account/models/account_move.py#L3500-L3518

### Steps to reproduce:
- Install `account_accountant`
- Login as Marc Demo (By default it's a Book Keeper)
- Create and post a Bill (Deferred Date: 01/01 to 31/12)
You may need to display the Deferred Date, that's hidden by default
- Open the Deferral Entries with the Smart button
- Manually create or duplicate an entry in that same journal and post it
- Return to the Bill and try to "Reset to Draft" 

Before the fix, the error is raised

opw-6113349

The calendar event for a paid appointment is created from account.move._post() once the invoice is confirmed by the payment transaction. At that point there is no website request, so env.company falls back to the user's default allowed company instead of the company the booking was made on. The attendee invitation mail rendered from the new event then carries that default company's branding in its header and footer rather than the company the customer booked on.

Read the booking's company from the existing record it already carries (its invoice in the direct payment flow, its sale order line in the eCommerce flow added by website_appointment_sale) and re-apply it via with_company when creating the calendar event so the mail layout picks the right company. The lookup is exposed as a hook on calendar.booking so each module can extend it for its own payment record.

Reachable since the feature was added in https://github.com/odoo/enterprise/commit/ce6bc7150457c8f4da331abb359ec99badca5ab3.

Steps to reproduce:
1. In a multi-company environment with two companies A and B, give the staff user access to both with company A as their default.
2. Create a website tied to company B.
3. Activate the Demo payment provider in test mode on both companies.
4. From company B, create an appointment type with an up-front payment, staffed by that user and tied to company B's website.
5. From company B's public website, open the appointment page, pick a slot, fill in the customer info and proceed to payment.
6. Pay via Demo.
7. Open the attendee invitation email in the mail catcher.

=> The email header and footer show company A instead of company B.

Ticket [link](https://www.odoo.com/odoo/project.task/5106795)
opw-5106795