Issue
-----
Gantt view's drag & drop allows the user to change the value of readonly fields if they are stored.

E.G. in the Planning view of MRP, grouped by Work Center > Product, dragging & dropping can change the product of the WO if the user is not careful and drops the WO on top of another product's WO.

Steps to reproduce
-----
- Have 2 products
- Create a MO for product 1 with a WO at work center 1, plan it
- Create a MO for product 2 with a WO at work center 2, plan it
- Got to Manufacturing, Planning, Planning by Work Center
- Add a custom group (by product)
- Drag the WO of WC2 and drop it on top of the other WO

> Both the WC and the product of the second WO change

Cause
-----
The example problem is only for versions 17.0 & 18.0 where the `product_id` field of `mrp.workorder` is both readonly and stored.

https://github.com/odoo/odoo/blob/31e46a841b38de0f99beb1844f985bc670621486/addons/mrp/models/mrp_workorder.py#L34

While the user cannot change the field value manually, automatic actions such as a gantt view drag & drop can change its' value by passing it to `write` since the field is stored. This does not pose any problem for related fields that are not stored.

More broadly, gantt views should not ignore the `readonly` attribute of fields.

Solution
-----
Add a new `o_gantt_readonly` class to all cells of rows grouped by a readonly field - and their "child" rows. For example, if the grouping is done by "Work Center > Product > Quality Check" and "Product" is readonly, rows grouped by either "Product" or "Quality Check" will be marked as readonly.

When the user drags a pill, dynamically remove the class from cells of the same "child group". The class will then be added back upon pill drop.

-----
Ticket:
opw-4875366

Forward-Port-Of: odoo/enterprise#100088
Forward-Port-Of: odoo/enterprise#94166

Step to reproduce:
- for Spain localization, in developer mode:
- Go to Balance sheet 
- Select either report 'Balance sheet - SMEs (ES) or Complete Balance Sheet (ES)
- Click on the parameters button
- Click on the "Accounts Coverage Report"

Observation:
- we receive a traceback
```
psycopg2.errors.InvalidTextRepresentation: invalid input syntax for type integer: "%(balance_sheet_11700_account)d"
LINE 1: ...ccount_tag" WHERE ("account_account_tag"."id" IN ('%(balance...
```

Cause:
- few records used a wrong format style for values of `domain_formula`
- These faulty domains were not [evaluated](https://github.com/odoo/odoo/blob/2070e30c540a066fb80851527e5e54e97fb23c4b/addons/account/models/account_report.py#L450-L453), but inserted into database as is.
- when browsing account.tag record using these domain, record ids were expected,
instead we got its string representation , causing traceback 

https://github.com/odoo/enterprise/blob/8fa6fb27d2a79ee299361b281dc82182feee5860/account_reports/models/account_report.py#L5679-L5680

Fix:
- we fix the data file, which is properly evaluated and stored in database.
- Manifest's data file order is changed, so that account tags is loaded first.

opw-5224114

Forward-Port-Of: odoo/enterprise#99865
Forward-Port-Of: odoo/enterprise#98745

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/4f8366721 [REL] 18.4.18 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/83c393f62 [FIX] Spreadsheet: fix scroll on ios [Task: 5270869](https://www.odoo.com/odoo/2328/tasks/5270869)
https://github.com/odoo/o-spreadsheet/commit/948c51e86 [FIX] headers_overlay: disable interaction in read-only mode [Task: 5182854](https://www.odoo.com/odoo/2328/tasks/5182854)
https://github.com/odoo/o-spreadsheet/commit/3ce3152f7 [FIX] spreadsheet: fix button height [Task: 5253888](https://www.odoo.com/odoo/2328/tasks/5253888)
https://github.com/odoo/o-spreadsheet/commit/16b2e4115 [FIX] composer: change mode to editing when composer cursor selection changes [Task: 5226615](https://www.odoo.com/odoo/2328/tasks/5226615)
https://github.com/odoo/o-spreadsheet/commit/e4b3ebef8 [FIX] SidePanel: reset initial props on Model change [Task: 5059484](https://www.odoo.com/odoo/2328/tasks/5059484)
https://github.com/odoo/o-spreadsheet/commit/62dfe8a88 [FIX] composer: Enter/Tab confirm when assistant is force-closed [Task: 5153666](https://www.odoo.com/odoo/2328/tasks/5153666)
https://github.com/odoo/o-spreadsheet/commit/2a23dddf4 [FIX] reference_type: add single quotes for sheet names with spaces [Task: 5244798](https://www.odoo.com/odoo/2328/tasks/5244798)

Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>

Step to reproduce:
- for Spain localization, in developer mode:
- Go to Balance sheet 
- Select either report 'Balance sheet - SMEs (ES) or Complete Balance Sheet (ES)
- Click on the parameters button
- Click on the "Accounts Coverage Report"

Observation:
- we receive a traceback
```
psycopg2.errors.InvalidTextRepresentation: invalid input syntax for type integer: "%(balance_sheet_11700_account)d"
LINE 1: ...ccount_tag" WHERE ("account_account_tag"."id" IN ('%(balance...
```

Cause:
- few records used a wrong format style for values of `domain_formula`
- These faulty domains were not [evaluated](https://github.com/odoo/odoo/blob/2070e30c540a066fb80851527e5e54e97fb23c4b/addons/account/models/account_report.py#L450-L453), but inserted into database as is.
- when browsing account.tag record using these domain, record ids were expected,
instead we got its string representation , causing traceback 

https://github.com/odoo/enterprise/blob/8fa6fb27d2a79ee299361b281dc82182feee5860/account_reports/models/account_report.py#L5679-L5680

Fix:
- we fix the data file, which is properly evaluated and stored in database.
- Manifest's data file order is changed, so that account tags is loaded first.

opw-5224114

Forward-Port-Of: odoo/enterprise#98745

Issue
-----
Gantt view's drag & drop allows the user to change the value of readonly fields if they are stored.

E.G. in the Planning view of MRP, grouped by Work Center > Product, dragging & dropping can change the product of the WO if the user is not careful and drops the WO on top of another product's WO.

Steps to reproduce
-----
- Have 2 products
- Create a MO for product 1 with a WO at work center 1, plan it
- Create a MO for product 2 with a WO at work center 2, plan it
- Got to Manufacturing, Planning, Planning by Work Center
- Add a custom group (by product)
- Drag the WO of WC2 and drop it on top of the other WO

> Both the WC and the product of the second WO change

Cause
-----
The example problem is only for versions 17.0 & 18.0 where the `product_id` field of `mrp.workorder` is both readonly and stored.

https://github.com/odoo/odoo/blob/31e46a841b38de0f99beb1844f985bc670621486/addons/mrp/models/mrp_workorder.py#L34

While the user cannot change the field value manually, automatic actions such as a gantt view drag & drop can change its' value by passing it to `write` since the field is stored. This does not pose any problem for related fields that are not stored.

More broadly, gantt views should not ignore the `readonly` attribute of fields.

Solution
-----
Add a new `o_gantt_readonly` class to all cells of rows grouped by a readonly field - and their "child" rows. For example, if the grouping is done by "Work Center > Product > Quality Check" and "Product" is readonly, rows grouped by either "Product" or "Quality Check" will be marked as readonly.

When the user drags a pill, dynamically remove the class from cells of the same "child group". The class will then be added back upon pill drop.

-----
Ticket:
opw-4875366

Forward-Port-Of: odoo/enterprise#100088
Forward-Port-Of: odoo/enterprise#94166

1) Update l10n_uy_edi translations.
2) When an uruguayan xml file is uploaded on a purchase journal it could contain the information of more than one CFE but before this commit only the first CFE was processed. Now all the CFEs are processed.
3) Add suffix '-manual' for new vendor edi documents uuid that are created by drag and drop xml file. 
4) Create xml attachment in the edi document if it is created by drag and drop xml file. 
5) Add suffix '-notification' for new vendor edi documents uuid that are created by 'UY: Create vendor bills (sync from Uruware)'. 
6) Cron is run by batches (size=10).
7) Add tests.

The suffixes -manual and -notification are used to differentiate between EDI documents generated manually and those generated automatically. This is useful to determine whether the document was created by a user or by an automated process, also helps users identify its origin more easily and also it is useful for debugging and tracking purposes.

Task Adhoc side: 43467
Task latam side: 1355

Forward-Port-Of: odoo/enterprise#99308
Forward-Port-Of: odoo/enterprise#86829

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/57b11b85d [REL] 18.3.27 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/6487f6d0e [FIX] spreadsheet: fix button height [Task: 5253888](https://www.odoo.com/odoo/2328/tasks/5253888)
https://github.com/odoo/o-spreadsheet/commit/8ec4b1cd1 [FIX] headers_overlay: disable interaction in read-only mode [Task: 5182854](https://www.odoo.com/odoo/2328/tasks/5182854)
https://github.com/odoo/o-spreadsheet/commit/e076525ba [FIX] composer: change mode to editing when composer cursor selection changes [Task: 5226615](https://www.odoo.com/odoo/2328/tasks/5226615)
https://github.com/odoo/o-spreadsheet/commit/e8d8bcd9b [FIX] SidePanel: reset initial props on Model change [Task: 5059484](https://www.odoo.com/odoo/2328/tasks/5059484)

Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>

When duplicating a delivery linked to a sale order and changing the product on the duplicated picking, validating the return could lead to an error when validating the original picking of the initial product.

The issue occurred because the average price computation was mixing stock moves of different products when consuming valuation layers, leading to a UoM singleton error.

Steps to reproduce:
- Create storable products P1 and P2:
  - Category: AVCO
  - P1 UoM: Unit
  - P2 UoM: Dozen
- Create a sale order with 1 unit of P1
- Confirm the SO
- Open the generated picking
- Duplicate it → a new picking is created and still linked to the same SO
- Change the product on the duplicated picking to P2
- Confirm and validate it
- Create a return on this picking and validate it
- Go back to the original picking of P1 and try to validate it

Problem:
A UserError is raised due to mixed products in the average price computation, resulting in a “Expected singleton: uom.uom(...)”

This fix ensures that average price is computed only using stock moves belonging to the same product.

opw-5027089

Forward-Port-Of: odoo/odoo#236706

Currently an error occurs when user uninstalls the `databases` module.

**Steps to replicate:**
* Install and uninstall databases

**Error:**
`ValueError: Invalid field project.project.database_hosting in condition ('database_hosting', '=', False)`

**Root cause:**
* This error happens because when the user installs `databases`, record rule [1] is created by the module and it overrides rule [2]. Later, when databases is uninstalled, rule [1] is still there, but it tries to access the field 'database_hosting' [3], which was removed during the uninstall. Since that field no longer exists, it causes an error.

**Solution:**
* Revert the domain back to the one defined in project module.

[1]:
https://github.com/odoo/enterprise/blob/437f724c182ddf22bd3df9a7e1582ffa4b29e33b/databases/security/databases_security.xml#L43-L46 
[2]:
https://github.com/odoo/odoo/blob/9333df06e15134df92efed765cf95db38c0dfede/addons/project/security/project_security.xml#L57-L62 
[3]:
https://github.com/odoo/enterprise/blob/437f724c182ddf22bd3df9a7e1582ffa4b29e33b/databases/models/project_project.py#L17-L26

sentry-7035410943

Forward-Port-Of: odoo/enterprise#99987

Problem
--------

In v18.0, the day billing period was removed from the sale.subscription.plan model.

For our use case, we require daily subscriptions, so we added this value back to the billing_period_unit selection field via inheritance.

However, this customization causes an error (a KeyError) when accessing the customer portal at /my/subscriptions/<int:order_id>. This is because the controller logic relies on a hardcoded list of periods and does not account for the new custom "day" value.

- Screenshot Order with plan Daily: 
<img width="1246" height="483" alt="image" src="https://github.com/user-attachments/assets/5dc5ca0d-a2f2-434d-8183-15a0424d9f34" />

- Screenshot when trying to get in order on the website: 
<img width="1250" height="776" alt="image" src="https://github.com/user-attachments/assets/5b10504e-71e2-4c13-8611-39e8a41e05d1" />


Proposed Solution
--------

This PR improves the subscription portal by dynamically retrieving billing periods instead of using a hardcoded list.

The portal now reads the available options directly from the billing_period_unit field's selection (i.e., self.env['sale.subscription.plan']._fields['billing_period_unit'].selection).

This improves maintainability, as future changes to the field's selection will be automatically reflected without requiring code modifications. This makes the portal robust and automatically compatible with any custom periods added via inheritance.

- 
<img width="1331" height="752" alt="image" src="https://github.com/user-attachments/assets/4f7be6c3-d96b-4525-8e23-6e1323adabde" />

Forward-Port-Of: odoo/enterprise#100084
Forward-Port-Of: odoo/enterprise#99207

**Issue:**
When editing budget values in the Profit & Loss report, users see floating-point precision errors (e.g., 0.999999 instead of 1.00) in the input field, even though the display shows the correct rounded value.

**Steps to Reproduce:**
1. Go to Accounting → Reporting → Profit and Loss Report
2. Enable Column Budget
3. Enter budget value: 5.00
4. Save → Value displays correctly as: 5.00 ✓
5. Click to edit the same cell
6. Input field shows: 5.000000000174602 ✗ (instead of 5.00)
7. Save without changes → Display shows: 5.00 ✓
8. Edit again → Still shows: 5.000000000174602 ✗

**Root Cause:**
The frontend reads from cell['no_format'] when populating the edit input field. This field receives the raw column_value which contains floating-point precision errors accumulated during aggregation operations. While the display formatting applies rounding, the edit mode receives the unrounded value.

**Solution:**
Round column_value using float_round() immediately after detecting an editable budget column, before the value is used anywhere. This ensures both the display path and edit path receive the same properly rounded value based on the company's currency decimal places.

opw-5158862

Forward-Port-Of: odoo/enterprise#98478

Currently, when creating a DHL shipment with an export declaration that includes a customer reference, there is a misspelling of the field 'recipientReference' as 'recepientReference'. This causes validation errors when communicating with the DHL API.

In addition, the datetime format used for the planned shipping date and time does not conform to the expected format specified by DHL.

Steps to reproduce spelling issue:
1. Create a Sales Order with a customer reference and a deliverable product.
2. Validate the SO.
3. Go to the delivery, select DHL as carrier, and confirm. → Error: Validation error #/content/exportDeclaration: extraneous key
  [recepientReference] is not permitted.

Steps to reproduce datetime issue:
1. Create a delivery using the DHL carrier.
2. Confirm the delivery.
3. Return the delivery.
4. Click "Print Return Label". → Error: Bad request #/plannedShippingDateAndTime is not well formatted
  (expected format: '2010-02-11T17:10:09 GMT+01:00').

Official DHL documentation:
https://developer.dhl.com/sites/default/files/2025-11/dpdhl-express-api-3.1.1_swagger.yaml

opw-5024363

Forward-Port-Of: odoo/enterprise#98981

*: {stock_barcode_,}quality_control
#### There are two issues addressed in this PR:

1) In the barcode app, quality checks triggered at validation includes quality checks related to unpicked products.
2) Quality check related to product without set lots are triggered.

### Steps to reproduce:

- Create a storable products product A tracked by SN
- Create a control points of type pass/fail on receipts control by
  quantity on product A
- Create and confirm a receipt with a move 2 x product A
- Open the receipt in the barcode app
- Scan product A > Scan SN001
- Click on Quality Check
#### > Both QC's are displayed to be processed

### Expected behavior:

Only the QC related to the scanned SN should be processed as it is the only unit that will be moved at validation.

### Cause of the issue:

Only picked move lines are considered to be processed in the barcode app. However, the `check_quality` triggered by clicking on the quality check button only check if the move related to the move line is picked:
https://github.com/odoo/enterprise/blob/9fe45b673c02a98e6dd6b3997f19a2018a76df09/quality_control/models/stock_picking.py#L64-L72

### Fix:

Relying the `barcode_trigger` context key will ensure a uniform behavior between the QC's displayed to be processed directly from the QC button and from these displayed at validation since this context key is already used at validation:
https://github.com/odoo/enterprise/blob/9fe45b673c02a98e6dd6b3997f19a2018a76df09/stock_barcode/static/src/models/barcode_model.js#L581-L590

Note we all changed the default return value of the `check_quality` from `False` to `True` here:
https://github.com/odoo/enterprise/blob/9fe45b673c02a98e6dd6b3997f19a2018a76df09/quality_control/models/stock_picking.py#L71-L73
because this method is called in the `pre_action_done_hook` during the `button_validate` of the picking:
https://github.com/odoo/odoo/blob/a97d3c772001f4f0b9df66d28c1c8f19358898e0/addons/stock/models/stock_picking.py#L1415-L1421
https://github.com/odoo/enterprise/blob/9fe45b673c02a98e6dd6b3997f19a2018a76df09/quality_control/models/stock_picking.py#L91-L96
and since a result that is not `True` is expected to be an action that should be processed prior to validation, returning `False` would make it impossible to proceed with a validation in case the `check_quality` is called and there is no check to process.

Task: 4716252
opw-5010764

Forward-Port-Of: odoo/enterprise#99799
Forward-Port-Of: odoo/enterprise#99565

- Install Accounting and `l10n_de_reports`
- Switch to a German company
- Create a bill:
  * Price: `100.00`
  * Taxes: `19%`
- Edit the tax total with the pencil button
- Go to "Accounting / Reporting / Audit Reports / General Ledger"
=> The tax amount is the one that has been edited manually
- Download `Datev DATA (zip)`
- Open `EXTF_accounting_entries.csv` file

The total amount in the file is the one before the edition of the tax amount.

The Datev data depends on `price_total` field of the invoice lines, but this field is not updated when the tax amount is edited manually.

We now check the total by adding `price_total` of each invoice line and the total amount defined in `tax_totals` field. If there is a difference, compute the delta for each tax group and split it between all the lines where a tax of that group is used.

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

Forward-Port-Of: odoo/enterprise#100244
Forward-Port-Of: odoo/enterprise#98684

Step to reproduce:
- for Spain localization, in developer mode:
- Go to Balance sheet 
- Select either report 'Balance sheet - SMEs (ES) or Complete Balance Sheet (ES)
- Click on the parameters button
- Click on the "Accounts Coverage Report"

Observation:
- we receive a traceback
```
psycopg2.errors.InvalidTextRepresentation: invalid input syntax for type integer: "%(balance_sheet_11700_account)d"
LINE 1: ...ccount_tag" WHERE ("account_account_tag"."id" IN ('%(balance...
```

Cause:
- few records used a wrong format style for values of `domain_formula`
- These faulty domains were not [evaluated](https://github.com/odoo/odoo/blob/2070e30c540a066fb80851527e5e54e97fb23c4b/addons/account/models/account_report.py#L450-L453), but inserted into database as is.
- when browsing account.tag record using these domain, record ids were expected,
instead we got its string representation , causing traceback 

https://github.com/odoo/enterprise/blob/8fa6fb27d2a79ee299361b281dc82182feee5860/account_reports/models/account_report.py#L5679-L5680

Fix:
- we fix the data file, which is properly evaluated and stored in database.
- Manifest's data file order is changed, so that account tags is loaded first.

opw-5224114

Forward-Port-Of: odoo/enterprise#99865
Forward-Port-Of: odoo/enterprise#98745

[FIX] l10n_fr_reports: unbalanced Balance Sheet when coming from the 2024 CoA

https://github.com/odoo/odoo/commit/8f3a86925e0301c15ca93b64d6237b69a534d71a introduced a new version of the French CoA, legally mandatory starting in 2025. Doing so, it also adapted the P&L and BS reports accordingly. However, it did not take into account the fact that some deprecated account codes would disappear from the P&L, causing the BS to be unbalanced when computing the retained earnings (by calling the P&L with a forced date_scope to run it on the full history).

We fix that by reinjecting the balance of the missing Income and Expense accounts in the computation of the BS's Retained Earnings line.

opw-5212801

===============================================================

[FIX] l10n_fr_reports : add new accounts in P&L

Backport from https://github.com/odoo/enterprise/commit/eb35916f4f5a45e0c11919e0ee1a16e0caee010f , which was done in master for 18.2, but should have targetted older versions as well.

Forward-Port-Of: odoo/enterprise#100116
Forward-Port-Of: odoo/enterprise#100077

Steps:
- Create an MTO product.
- Create an SO for 10 units and confirm.
- Deliver 5 on the first picking, validate, and create the backorder.
- Print the delivery slip of the first (done) picking.

Before:
- MTO: Ordered = 5, Delivered = 5, Remaining = 5.
- Normal product: Ordered = 10, Delivered = 5, Remaining = 5.

Cause:
- _get_aggregated_properties builds a display key including the description:
  line_key = f"{product.id}_{product.display_name}_{description}_{uom.id}_{move.product_packaging_id}".
- In MTO, backorder delivery moves are regenerated and sale_stock recomputes description_picking from the SO line, so backorders no longer share the same line_key and previous quantities are not merged.

Fix:
- Introduce _get_group_key_from_move to group sale moves by sale_line_id (fallback: product + UoM).
- For each picking, compute Ordered as the SO line quantity (in report UoM) minus quantities delivered on preceding pickings for that group.
- Keep the original line_key-based behavior for non sale-related moves and for empty moves.

opw-5112467

**Issue**
A route explicitly set on a sale order line is ignored: the system falls back to product-level routes.

**Steps to reproduce**
1. Activate multi-route.
2. Unarchive the MTO route.
3. Create a product.
4. Enable MTO + Manufacture on the product.
5. Create a sale order using this product.
6. Set the Buy route on the SO line.
7. Confirm the order.
→ A Manufacturing Order is created instead of a PO.

**Cause**
This regression originates from the changes introduced in https://github.com/odoo-dev/odoo/commit/2713876dbc70d3984e584a9037a2206dcda4e84a, where `propagate_warehouse_id` was removed and associated info began to be propagated
through stock moves instead.

In 19.0, the route of the rule started being injected into the move:
https://github.com/odoo/odoo/blob/af4365421bc7ba990420789c12c98270d723fa1a/addons/stock/models/stock_rule.py#L367

To avoid infinite loops (e.g., WH1 resupplying WH2 and vice-versa), `_prepare_procurement_values` then filters out these injected routes:
https://github.com/odoo/odoo/blob/af4365421bc7ba990420789c12c98270d723fa1a/addons/stock/models/stock_move.py#L1674-L1683

Unfortunately, whenever the `location_id` has a warehouse, the filtering applies to all `route_ids`, including those explicitly set by the user (e.g., on a sale order line)

As soon as `route_ids` is cleared, `_get_rule` stops considering SO-line routes
(first priority):
https://github.com/odoo/odoo/blob/dab7c5821e627bc7120660778a288cb521a223d3/addons/stock/models/stock_rule.py#L599C13-L600C89

and falls back to product routes:
https://github.com/odoo/odoo/blob/dab7c5821e627bc7120660778a288cb521a223d3/addons/stock/models/stock_rule.py#L604

**Solution**
Revert the workaround that injected the rule's `route_id` into the move (added because `propagate_warehouse_id` no longer existed), and instead propagate the warehouse information directly in the inter-company case.

Concretely:
- Stop injecting the rule's `route_id` into the move:
  https://github.com/odoo/odoo/blob/af4365421bc7ba990420789c12c98270d723fa1a/addons/stock/models/stock_rule.py#L367
- Always keep the user's `route_ids` intact, no more filtering.
- Explicitly propagate the warehouse coming from the rule in the inter-company
  case, restoring the intent of `propagate_warehouse_id`:
  https://github.com/odoo/odoo/blob/a7b504a3f5845feff8b676cc02ecf2d7b3489b7f/addons/stock/models/stock_move.py#L1655-L1656

This preserves manually-set routes (such as on SO lines) while still ensuring inter-company transfers work reliably.

opw-5170290

Step to reproduce:
- for Spain localization, in developer mode:
- Go to Balance sheet 
- Select either report 'Balance sheet - SMEs (ES) or Complete Balance Sheet (ES)
- Click on the parameters button
- Click on the "Accounts Coverage Report"

Observation:
- we receive a traceback
```
psycopg2.errors.InvalidTextRepresentation: invalid input syntax for type integer: "%(balance_sheet_11700_account)d"
LINE 1: ...ccount_tag" WHERE ("account_account_tag"."id" IN ('%(balance...
```

Cause:
- few records used a wrong format style for values of `domain_formula`
- These faulty domains were not [evaluated](https://github.com/odoo/odoo/blob/2070e30c540a066fb80851527e5e54e97fb23c4b/addons/account/models/account_report.py#L450-L453), but inserted into database as is.
- when browsing account.tag record using these domain, record ids were expected,
instead we got its string representation , causing traceback 

https://github.com/odoo/enterprise/blob/8fa6fb27d2a79ee299361b281dc82182feee5860/account_reports/models/account_report.py#L5679-L5680

Fix:
- we fix the data file, which is properly evaluated and stored in database.
- Manifest's data file order is changed, so that account tags is loaded first.

opw-5224114

Forward-Port-Of: odoo/enterprise#99865
Forward-Port-Of: odoo/enterprise#98745

Issue
-----
Gantt view's drag & drop allows the user to change the value of readonly fields if they are stored.

E.G. in the Planning view of MRP, grouped by Work Center > Product, dragging & dropping can change the product of the WO if the user is not careful and drops the WO on top of another product's WO.

Steps to reproduce
-----
- Have 2 products
- Create a MO for product 1 with a WO at work center 1, plan it
- Create a MO for product 2 with a WO at work center 2, plan it
- Got to Manufacturing, Planning, Planning by Work Center
- Add a custom group (by product)
- Drag the WO of WC2 and drop it on top of the other WO

> Both the WC and the product of the second WO change

Cause
-----
The example problem is only for versions 17.0 & 18.0 where the `product_id` field of `mrp.workorder` is both readonly and stored.

https://github.com/odoo/odoo/blob/31e46a841b38de0f99beb1844f985bc670621486/addons/mrp/models/mrp_workorder.py#L34

While the user cannot change the field value manually, automatic actions such as a gantt view drag & drop can change its' value by passing it to `write` since the field is stored. This does not pose any problem for related fields that are not stored.

More broadly, gantt views should not ignore the `readonly` attribute of fields.

Solution
-----
Add a new `o_gantt_readonly` class to all cells of rows grouped by a readonly field - and their "child" rows. For example, if the grouping is done by "Work Center > Product > Quality Check" and "Product" is readonly, rows grouped by either "Product" or "Quality Check" will be marked as readonly.

When the user drags a pill, dynamically remove the class from cells of the same "child group". The class will then be added back upon pill drop.

-----
Ticket:
opw-4875366

Forward-Port-Of: odoo/enterprise#100088
Forward-Port-Of: odoo/enterprise#94166

Steps to reproduce:
1. Go to Products > Create a new product.
2. Add or create a new attribute with a long text value.
3. Go to Sales > Open any quotation.
4. In the sale order line, click on "Catalog" and search for the created product.

Issue:
- The product image and attribute value text overflow outside the product card in the kanban view, causing layout misalignment and breaking the UI design.
<img width="647" height="225" alt="image" src="https://github.com/user-attachments/assets/afc592bb-e25a-4d81-882b-0e7cc7ad1064" />

Cause:
- The inner div containing the attribute text lacked overflow control, allowing long text to exceed the container width and pushing other elements.

Solution:
- Added the Bootstrap class `overflow-hidden` to the div element to ensure the image and text remain properly contained within the card layout.

<img width="587" height="171" alt="image" src="https://github.com/user-attachments/assets/580ce1e5-42bd-4c2d-b6bf-14315759626d" />



opw-5222002

Forward-Port-Of: odoo/odoo#235680
Forward-Port-Of: odoo/odoo#235214

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/f5bdbccc9 [REL] 19.0.11 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/6b7c8085a [FIX] Spreadsheet: fix scroll on ios [Task: 5270869](https://www.odoo.com/odoo/2328/tasks/5270869)
https://github.com/odoo/o-spreadsheet/commit/1a9de79be [FIX] borders: preserve side borders when combining External and All [Task: 5270171](https://www.odoo.com/odoo/2328/tasks/5270171)
https://github.com/odoo/o-spreadsheet/commit/42fa2e10a [FIX] headers_overlay: disable interaction in read-only mode [Task: 5182854](https://www.odoo.com/odoo/2328/tasks/5182854)
https://github.com/odoo/o-spreadsheet/commit/dd6124730 [FIX] spreadsheet: fix button height [Task: 5253888](https://www.odoo.com/odoo/2328/tasks/5253888)
https://github.com/odoo/o-spreadsheet/commit/c23e4925d [FIX] functions: ignore vectorized SUBTOTAL [Task: 5261987](https://www.odoo.com/odoo/2328/tasks/5261987)
https://github.com/odoo/o-spreadsheet/commit/7edc3b50b [FIX] release: make lastest [](https://www.odoo.com/odoo/2328/tasks/)
https://github.com/odoo/o-spreadsheet/commit/d59fcbf0d [FIX] composer: change mode to editing when composer cursor selection changes [Task: 5226615](https://www.odoo.com/odoo/2328/tasks/5226615)
https://github.com/odoo/o-spreadsheet/commit/2b5cd53d1 [FIX] SidePanel: reset initial props on Model change [Task: 5059484](https://www.odoo.com/odoo/2328/tasks/5059484)
https://github.com/odoo/o-spreadsheet/commit/7ae8c7666 [FIX] composer: Enter/Tab confirm when assistant is force-closed [Task: 5153666](https://www.odoo.com/odoo/2328/tasks/5153666)
https://github.com/odoo/o-spreadsheet/commit/eccc2e02f [FIX] reference_type: add single quotes for sheet names with spaces [Task: 5244798](https://www.odoo.com/odoo/2328/tasks/5244798)
https://github.com/odoo/o-spreadsheet/commit/b95dcae83 [FIX] pivot: raise pivot size limit [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)

Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>

### Issue:
In GCC invoices the product names are not in both languages.

### Steps to reproduce:
- Install "l10n_sa" and switch to a Saudi company
- Have a product with its name translated in both English and Arabic
- Create an invoice with this product, print it
- The product name is only displayed in the language of the partner

### Cause:
[This refactor](https://github.com/odoo/odoo/commit/1cddcab8b8626b34c437a51d320b0a3e4698dae7) removed the [part of the code responsible for displaying the product in both languages](https://github.com/odoo/odoo/blob/f9090fff6b3564c0d7ce2363a283b81ea10b3906/addons/l10n_gcc_invoice/views/report_invoice.xml#L286-L293). Now only `line.name` is displayed.

### Solution:
We use the same XML architecture as in 18.0.
As `line.name` is composed of several fields combined we need to check if the English and/or Arabic name is in `line.name` to display it or not.

We use a replace in the xpath to add `dir="rtl"` on `line.name`. This ensure that when the partner lang is Arabic then `line.name` is displayed right to left.

### Note:
`line.name` can contain other field like `description_sale` or `description_purchase` that will still be displayed in only one language.

opw-5219783

### Issue:
In this issue, when a quotation template is used in sale order, the end line is missing between name and description in the invoice pdf.

#### Steps to reproduce:
1- Install a db with sale and invoicing installed
2- Create a quotation template, and add a description in the line.
3- Create a quotation with the created template.
4- Confirm the order and create an invoice for the sale order.
5- Print the pdf, as seen the name and description are shown in the same line, while if the sale order was created without a template, we would have seen the description from product in the next line.

### Cause:
There is a mismatch between `line.name` when it's from template and when it's from product itself, causing this issue.

In the case, the line is not coming from template we have: https://github.com/odoo/odoo/blob/aaad780e897e941a3d5cf9b3a881252907ba266a/addons/sale/models/sale_order_line.py#L405-L416 in which:
https://github.com/odoo/odoo/blob/aaad780e897e941a3d5cf9b3a881252907ba266a/addons/sale/models/sale_order_line.py#L432-L435 https://github.com/odoo/odoo/blob/aaad780e897e941a3d5cf9b3a881252907ba266a/addons/product/models/product_product.py#L852-L861

Which means the name will be
```python
product_id.display_name + product_id.description_sale +
line._get_sale_order_line_multiline_description_variants()
```

While when the quotation is coming from template the name is:
```python
template_line.name +
line._get_sale_order_line_multiline_description_variants()
```
As `template_line.name` is the template line description, we can add the `product_id.display_name` in `_compute_name` so both logic match.

opw-5130171

**Steps to Reproduce:**

1. create test ``Float`` field in model ``A`` with ``digits`` args
2. create ``Many2One`` field with comodel ``A``  and then create Float Field in ``B Model`` with related ``A`` model test and store True

**Issue:**
  1. ``column_type`` for both model table will be different. For ``test field in model A`` the ``column_type`` will be ``numeric``. But for the related field ``column_type`` ``float`` it should be ``numeric``. This happen because the @lazy_propery it hold the ``column_type`` which is ``float8`` and other related attributes from ``setup_related`` before that ``_digits`` have the null value. So, from [here](https://github.com/odoo-dev/odoo/blob/a9398502260fa57573b88fd62ca3f554e0685c7b/odoo/fields.py#L772) it remains ``float8`` it should update with ``numeric``

   **Second issue comes From odoo 18.3**:=

during upgrade if any new ``module`` is intalled due to dependency change and inherits the same model that is ``A``. 
Due to ``_auto_init`` it will recompute this related field  because due to this newly [commit](https://github.com/odoo/odoo/commit/f5ce6784fce1ae27c3e92090b3723e9d4ce45808) clear the columns column becomes [``False``] and [``not column``] becomes true  from ``update_db`` and same reason as above  it didn't return from [here](https://github.com/odoo/odoo/commit/f5ce6784fce1ae27c3e92090b3723e9d4ce45808#diff-956d895aa67961bac940841f7c3d1e10eb8ecabec82ef017803c4a6a3bb7cd22R1074) because column type is ``float8`` which leads to  memory of unecessary compute which shouldn't do in first place.

**FIX:**

Remove the ``column_type`` and let it get again as soon ``_digits`` attribute add.

before fix:-
```
SELECT column_name, data_type FROM information_schema.columns WHERE table_name = 'account_move_line' AND column_name = 'test_line_id';
 column_name  |    data_type
--------------+------------------
 test_line_id | double precision
(1 row)

```

After fix:-
```
SELECT column_name, data_type FROM information_schema.columns WHERE table_name = 'account_move_line' AND column_name = 'test_line_id';
 column_name  | data_type
--------------+-----------
 test_line_id | numeric
(1 row)

```
opw-5222760
upg-3253635

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

Issue
-----
In 3step manufacturing, changing the pre-prod -> prod rule to MTSO doesn't have the expected behaviour. That is, if there is an insufficient quantity of component present in pre-prod, updating the producing qty doesn't update the replenishment quantity.

Steps to reproduce
-----
- Enable warehouses and multi-step routes
- Set warehouse manufacturing to 3 step
- Edit the 3 step production route
	- Change the pre-prod -> prod rule to mts else mto
- Create a product "Comp"
	- Set a quantity of 5 in location pre-prod
- Create a product "Prod"
	- Add a BoM with "Comp" as component
- Create a MO for 10 of Prod
- Confirm MO
> There is a transfer stock -> pre-prod for 5 of Comp
- Open the production quantity wizard, update value to 12 and confirm
> The transfer still shows 5 of Comp instead of the needed 7

Cause
-----
Changing the production quantity updates the raw moves of the MO. This triggers a write on the move with the new `product_uom_qty` so we do a `run_procurement`

https://github.com/odoo/odoo/blob/322c6d0468bf79e9d29e1375c49aa13d4a7b7a67/addons/mrp/models/stock_move.py#L481-L485

Before actually running any procurement we do

https://github.com/odoo/odoo/blob/322c6d0468bf79e9d29e1375c49aa13d4a7b7a67/addons/mrp/models/stock_move.py#L492

Since the procurement group's method is `mts_else_mto`, when we go through

https://github.com/odoo/odoo/blob/322c6d0468bf79e9d29e1375c49aa13d4a7b7a67/addons/stock/models/stock_move.py#L2329-L2332

we go into the `else` part and set the move's `procure_method` to mts.

This means that, in the `run_procurement` method

https://github.com/odoo/odoo/blob/322c6d0468bf79e9d29e1375c49aa13d4a7b7a67/addons/mrp/models/stock_move.py#L504

is not true, so we don't add any procurement to run.

Solution
-----
In `_adjust_procure_method` we update the move's rule to the MTSO one we found

https://github.com/odoo/odoo/blob/322c6d0468bf79e9d29e1375c49aa13d4a7b7a67/addons/stock/models/stock_move.py#L2328

This means that we can update the check in `run_procurement` to also add a procurement to run if the move's rule is MTSO.

-----
Ticket:
opw-5008871

**Problem:**
when selling a product valued by lot
and chosing a lot with a value of 0
the average value of the product
is used instead of 0.

**Steps to reproduce:**
- make sure your warehouse is in single step receipt and delivery
- create a product tracked by lot and valued by lot
- set the category as avco
- create a PO for a quantity of 10 and a unit price of 10
- confirm and open the receipt
- open the stock move widget on the stock move
- write "lot A" in the lot column and save
- validate
- create a PO for a quantity of 10 and a unit price of 0
- confirm and open the receipt
- open the stock move widget on the stock move
- write "lot B" in the lot column and save
- validate
- create a quotation for 1 quantity of your product
- confirm
- open the delivery
- open the stock move widget on the stock move
- in the 'pick from' column enter lot B and save
- validate
- open the valuation smart button

**Current behavior:**
the value of the stock valuation layer is -5

**Expected behavior:**
it should be 0

**Cause of the issue:**
Inside _prepare_out_svl_vals
lot.standard_price is 0 so the if condition
is false and we don't use the price of the lot
https://github.com/odoo/odoo/blob/cd2a241182cf56fc36d03df9f0afdcea30f682d2/addons/stock_account/models/product.py#L277

**fix:**
    deleting the lot.standard_price condition
    is not possible because when the lot is created
    at delivery it has no standard_price and in this
    case we want to use the standard_price of the
    product.
    (see test https://github.com/odoo/odoo/blob/d3835668349d466ed4ba27c9eacdbd3339f2ac37/addons/stock_account/tests/test_lot_valuation.py#L58)

opw-5077671

Issue
-----
Clicking the "pack" button in the catalog sometimes seems not to work and the product quantity remains unchanged.

Steps to reproduce
-----
- Enable packagings in settings
- Create a product
	- Set a vendor "Mom"
	- Add a packaging of some decimal number, eg 22.68
- Create a new purchase from "Mom"
- Open the catalog
- Click the product once
- Click the "pack" button 4 times (# of clicks required depends on the pack amount)
> The last click did not increase the product quantity

Cause
-----
Javascript floats are sometimes an approximation of the value rather than the value itself. This means that when we do

https://github.com/odoo/odoo/blob/0611a74cb52ca639b683ef158f8b4f2f347d08ad/addons/purchase/static/src/product_catalog/kanban_record.js#L33-L34

the flooring might sometimes get a close approximation and end up flooring down the packaging quantity.

In our example, `this.productCatalogData.quantity` should be `68.04` but is actually `68.03999999999999`. This leads to

`this.productCatalogData.quantity / packaging.qty` == `2.9999999999999996`

`Math.floor` then rounds it down to 2 so we end up with 2 + 1 = 3, which is the current packaging quantity so nothing changes.

-----
Ticket:
opw-5130865

Forward-Port-Of: odoo/odoo#235706

Steps to reproduce
-----
- Enable packages
- Create a stored Product "Prod"
- Add a quantity of 5 "Prod" in stock, in package "PACK1"
- Create a delivery for 3 units of "Prod" (so as to not move the whole package)
- Open the delivery in Barcode
- Scan "Prod"
- Put in pack

> The new line created for the remainder of the delivery is not taken from PACK1

Cause
-----
Put in pack causes the line to be split since there is some remaining quantity

https://github.com/odoo/enterprise/blob/139a123637369737ae7a58eebdbc2743ce134a64/stock_barcode/static/src/models/barcode_picking_model.js#L1586-L1593

Through which we create a new line

https://github.com/odoo/enterprise/blob/139a123637369737ae7a58eebdbc2743ce134a64/stock_barcode/static/src/models/barcode_model.js#L555-L559

With the origin package set as false by default

https://github.com/odoo/enterprise/blob/139a123637369737ae7a58eebdbc2743ce134a64/stock_barcode/static/src/models/barcode_model.js#L617-L624

-----
Ticket:
opw-5081496

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/498c3fcb1 [REL] 17.0.78 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/1e758de59 [FIX] headers_overlay: disable interaction in read-only mode [Task: 5182854](https://www.odoo.com/odoo/2328/tasks/5182854)
https://github.com/odoo/o-spreadsheet/commit/60a66b680 [FIX] composer: change mode to editing when composer cursor selection changes [Task: 5226615](https://www.odoo.com/odoo/2328/tasks/5226615)

Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>