Before this commit, when a Many field has a One inverse, assigning on the many field in a specific index lead to a crash.

The crash was fixed by https://github.com/odoo/odoo/pull/212963 But the resulting relations were still incorrect: the old record still was linked in the relation, and the new record was not properly linked in the inverse field.

This was happening due to similar typo in the inner code of JS models: deletion and addition of respectively old and new records were done with respectively
`recordList.delete(recordList)` and `recordList.add(recordList)`. The error comes from passing `recordList` instead of `recordList._.owner`, i.e. the old/new records.

The typo comes from `RecordUses` that also have methods `add` and `delete` and have `recordList` as 1st param. FYI, `RecordUses` is used for very-low level internal links of record being used by other records. Semantically this is like a relational field but the shape differs for improved computational complexity.

Forward-Port-Of: odoo/odoo#213203

**Patch description:**
- This commit addresses a perf issue in the `_compute_previous_order` compute of the `pos.order` model, which is particularly noticeable during db upgrade from `v17.0` to `v18.0` because field `previous_order_id` got introduced in `v18.0` or when installing the `l10n_fr_pos_cert` module on an existing db with many POS orders in `v18.0`.

- In both cases, the compute method is triggered for all `pos.order` records to assign the `previous_order_id`, causing significant delay due to per-record lookups.

**Example from a real DB with ~113k orders:**
```sql
apan_2840187=> select count(*) from pos_order;
 count
--------
 113342
(1 row)
```

**Observation:**
- Before the fix (compute took nearly 50 minutes):
```py
2025-05-29 06:31:12,587 28 INFO apan_2840187_18.0 odoo.modules.registry: module l10n_fr_pos_cert: creating or updating database tables
2025-05-29 06:31:12,799 28 INFO apan_2840187_18.0 odoo.models: Prepare computation of pos.order.previous_order_id
2025-05-29 07:17:37,855 28 INFO apan_2840187_18.0 odoo.modules.loading: loading l10n_fr_pos_cert/views/pos_views.xml
```

- After the fix (completed within 1 min):
```py
2025-05-30 06:56:59,510 24 INFO apan_2840187_18.0 odoo.modules.registry: module l10n_fr_pos_cert: creating or updating database tables
2025-05-30 06:56:59,584 24 INFO apan_2840187_18.0 odoo.models: Prepare computation of pos.order.previous_order_id
2025-05-30 06:57:12,531 24 INFO apan_2840187_18.0 odoo.modules.loading: loading l10n_fr_pos_cert/views/pos_views.xml
```

**Note:** The issue reported in the OPW was not originally about perf, but it was clearly exposed during the upgrade of the mentioned db.

opw-4812874
upg-2840187


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

Forward-Port-Of: odoo/odoo#212339

Problem:
In Chrome, when focused on the first input inside the link popover, pressing `Ctrl+Z` (undo) triggers `beforeinput` and `input` events on the editable element, even though the selection is within the popover input, not the editable area.

This leads to `addStep` being incorrectly triggered, adding DOM changes like the `a` tag to the history stack and resulting in unintended undo behavior.

Note: This issue doesn't occur in saas-18.2+ where the `a` tag is only added upon confirming the change, thus no mutation is pushed to history while editing.

Solution:
Intercept the `beforeinput` event on the editable and call `preventDefault()` if the selection is not currently within the editable, thereby stopping history pollution.

Steps to reproduce:
1. Type `/Link` and open the link popover.
2. Focus is automatically set on the first input.
3. Press `Ctrl+Z`.
4. Click on the editable area to close the popover.
5. Repeatedly press `Ctrl+Z` → the `a` tag is added/removed, corrupting undo history.

opw-4800278

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

Forward-Port-Of: odoo/odoo#210743

## Background

In Mexico, all accounts need to follow a pattern XXX.XX.XX or XXX.XX.XXX where additionally the first five digits must belong to a list of prefixes published by the SAT.

At the moment, several accounts created by default don't match the CoA pattern:

- 999000001 Cash Difference Gain
- 999000002 Cash Difference Loss.
- 999300000 Cash Discount Loss
-  999400000 Cash Discount Gain
-  999999 Undistributed Profits/Losses

## Fix

Given correct codes to the existing accounts and modifying data for some records:.

| Account                             | New code  | New name                                                                     | New Account type |
|-------------------------------------|-----------|------------------------------------------------------------------------------|------------------|
| 999000001 Cash Difference Gain      | 403.01.01 | Other Income                                                                 |  ~               |
| 999000002 Cash Difference Loss      | 601.84.02 |  ~                                                                           |  ~               |
| 999300000 Cash Discount Loss        | 402.01.01 | Returns, discounts or bonuses over sales and/or services at the general rate | other income     |
| 999400000 Cash Discount Gain        | 503.01.01 | Returns, discounts or bonuses over purchases                                 |  ~               |
| 999999 Undistributed Profits/Losses | 305.01.01 | Uncut Result                                                                 |  ~               |

---

opw-4288080

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

Forward-Port-Of: odoo/odoo#204019
Forward-Port-Of: odoo/odoo#196852

### Steps to reproduce:

- Create a storable product P with 10 units in stock.
- Inventory > Configuration > Warehouse Management > Operation Types
- Change the reservation Method of Delivery orders to Manual
- Create confirm and manually assign a delivery order for 3 units of P
- Process the DO in the barcode app, scan 1 unit of P
> The line should be 1/3
- Leave and come back
#### > The line is now at 1/1

Cause of the issue:

Leaving the barcode app launch a call of the `split_uncompleted_moves` in order to keep track of the initial reservation in the barcode app: https://github.com/odoo/enterprise/blob/577cb4b74a614d2dd472375b325706525ae591d7/stock_barcode/models/stock_move.py#L9-L11 
However, one of the issue of the current system is that these new moves are expected to be assigned by the `_action_confirm`: https://github.com/odoo/enterprise/blob/577cb4b74a614d2dd472375b325706525ae591d7/stock_barcode/models/stock_move.py#L37
But they are not in certain cases and we should therefore force re-assignation in that case:
https://github.com/odoo/odoo/blob/bf0461552effe806fdaa8f85f088be3c3f3be09d/addons/stock/models/stock_move.py#L1427-L1432

Enterprise: https://github.com/odoo/enterprise/pull/86394

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

Forward-Port-Of: odoo/odoo#212438
Forward-Port-Of: odoo/odoo#211616

### Steps to reproduce:

- Create a storable product P with 10 units in stock.
- Inventory > Configuration > Warehouse Management > Operation Types
- Change the reservation Method of Delivery orders to Manual
- Create confirm and manually assign a delivery order for 3 units of P
- Process the DO in the barcode app, scan 1 unit of P
> The line should be 1/3
- Leave and come back
#### > The line is now at 1/1

### Cause of the issue:

Leaving the barcode app launch a call of the `split_uncompleted_moves` in order to keep track of the initial reservation in the barcode app: https://github.com/odoo/enterprise/blob/577cb4b74a614d2dd472375b325706525ae591d7/stock_barcode/models/stock_move.py#L9-L11 However, one of the issue of the current system is that these new moves are expected to be assigned by the `_action_confirm`: https://github.com/odoo/enterprise/blob/577cb4b74a614d2dd472375b325706525ae591d7/stock_barcode/models/stock_move.py#L37 But they are not in certain cases and we should therefore force re-assignation in that case:
https://github.com/odoo/odoo/blob/bf0461552effe806fdaa8f85f088be3c3f3be09d/addons/stock/models/stock_move.py#L1427-L1432

Community: https://github.com/odoo/odoo/pull/211616

opw-4798349

Forward-Port-Of: odoo/enterprise#86727
Forward-Port-Of: odoo/enterprise#86394

**Steps to reproduce:**
- Install accountant and l10n_be_intrastat
- Switch to a Belgian company (e.g. BE Company CoA)

- Create a "Goods" product:
  * Product Type: Goods
  * Commodity Code: [any]
  * Country of Origin: [any]
- Create a "Service" product:
  * Product Type: Service
  * Commodity Code: [any]
  * Country of Origin: [any]

- Create an invoice:
  * Customer: [an European customer (not from Belgium)]
  * Invoice Lines: 1 line with the goods and 1 line with the service
- Confirm the invoice

- Go to "Accounting / Reporting / Audit Reports / Intrastat Reports"
- Select "Intrastat (Goods)" as Report
- Select the correct date to display the created invoice
- Click on the "XML" or "CSV" button to export the report

**Issue:**
In the exported file, the service product is also included. Only the goods should be in the exported file.

**Cause:**
Since a previous fix for "l10n_be_intrastat", "product_type_condition" condition is overridden with `SQL("AND (account_move_line.product_id IS NOT NULL)")` (https://github.com/odoo/enterprise/commit/1108467dcaedfacc28bf1751f6f8f4fc10f84043)
The original condition was:
`SQL("AND (account_move_line.product_id IS NULL OR prodt.type != 'service')")`
The part excluding the service products is removed by the overriding condition.

opw-4824257

Forward-Port-Of: odoo/enterprise#86919

**Problem:**
When internal transfer operation type has a manadatory destination
in barcode, the transfer can still be validated without destination
location scanned if it's a package

**Steps to reproduce:**
- In settings, enable the "packages" settings
- Navigate to Inventory/Configuration/Warehouse Management/
Operations Types
- Select "Internal Transfers", in the "Barcode App" page for Source
Location, select Mandatory Scan
- for "Destination Location" select "after each product"
- create a new storable product
- Navigate to Inventory/Operations/Physical Inventory
- Create a new line and select stock as the location
- Select your product
- In the package column, create a package and give it a name
- Set a quantity > Apply
- Open the barcode app, select operations and then internal
transfers
- Click on New and then Scan WH-Stock and the package name: PACK

**Current behavior:**
 The validate button is higlighted in green and clickable

**Expected behavior:**
Because we didn't scan a destination location it shouldn't be 
green and clickabel

**Cause of the issue:**

When a package barcode is scanned, when _processBarcode calls
_processPackage 
https://github.com/odoo/enterprise/blob/a60aea84d68587b1dfe1b6bfd20cb4fced0f7d46/stock_barcode/static/src/models/barcode_model.js#L1007
Inside _processPackage 
barcodeData.stopped is set to true (1)
and this.selectedLineVirtualId is set to false (2) 
https://github.com/odoo/enterprise/blob/a60aea84d68587b1dfe1b6bfd20cb4fced0f7d46/stock_barcode/static/src/models/barcode_picking_model.js#L1532-L1533
Because of (1) _processBarcode returns here 
https://github.com/odoo/enterprise/blob/a60aea84d68587b1dfe1b6bfd20cb4fced0f7d46/stock_barcode/static/src/models/barcode_model.js#L1008-L1011
and doesn't reach the part of the method where _selectLine is called  
https://github.com/odoo/enterprise/blob/a60aea84d68587b1dfe1b6bfd20cb4fced0f7d46/stock_barcode/static/src/models/barcode_model.js#L1181-L1182
(Inside _selectLine the value of selectedLineVirtualId is defined
https://github.com/odoo/enterprise/blob/a60aea84d68587b1dfe1b6bfd20cb4fced0f7d46/stock_barcode/static/src/models/barcode_model.js#L1269-L1274
)

So as a consequence of (1) and (2) the value of this.selectedLineVirtualID is 
false when a package is scanned

When the validate method is called when the user clicks on validate,
the method uses the value of this.selectedLine
https://github.com/odoo/enterprise/blob/a60aea84d68587b1dfe1b6bfd20cb4fced0f7d46/stock_barcode/static/src/models/barcode_picking_model.js#L777-L779
Because this.selectedLineVirtualID is false, get selectedLine returns false
https://github.com/odoo/enterprise/blob/a60aea84d68587b1dfe1b6bfd20cb4fced0f7d46/stock_barcode/static/src/models/barcode_model.js#L307-L309
So the if condition is false, the method is allowed to run and 
the error notification is not triggered


**Fix:**
After scanning a package there is no selectedLine so we need another
condition


opw-4590345

Forward-Port-Of: odoo/enterprise#86540
Forward-Port-Of: odoo/enterprise#83710

Currently, if there is an error while generation print reports the use of the IoT will return the generic error `Failed to send to printer' which does not lead to understand there is a hidden issue to begin with.

Steps to reproduce:
-------------------
1. Set up the iot and like the product labels report to a zebra printer
2. Modify the view of the product labels (`label_product_product_view`) to ensure there is an error during rendering (mistype a field name)
3. Go to a product and print labels
> Observation: Notification: Failed to send to printer

Why the fix:
------------
In the example given an error occurs when trying to render the label here:
https://github.com/odoo/enterprise/blob/968bf16c65a67791efd5fb94f5c95eaf09a47107/iot/static/src/iot_report_action.js#L50-L57

Technically the error makes it so that we fall into this catch block https://github.com/odoo/enterprise/blob/968bf16c65a67791efd5fb94f5c95eaf09a47107/iot/static/src/iot_report_action.js#L81-L88

We will now make a distinction between the RPC error and generic iot related error. If any error occur while making the RPC call we will now show the traceback. This should help anyone debugging.

opw-4571350

Forward-Port-Of: odoo/enterprise#84589