**Description of the problem**
Pressing backspace when the cursor is positioned at the very left edge of a button could trigger a traceback. Additionally, even if the crash did not occur, the backspace behavior would be incorrect, because the cursor would move across a zero-width non-breaking space (Zwnbsp) without deleting the first character to the left.

**How to reproduce**
In the `html_editor`, create a button. Click on its very left edge, then press backspace. An error is thrown.

**Why the problem happens**
1. Traceback when backspace is pressed
`LinkPlugin.handleDeleteBackward` assumes that `previousSibling` is an element node, and calls the `matches` method. However, when clicking on the very left edge of a button, the cursor is positioned such that the left sibling (`previousSibling`) is a text node. Text nodes do not implement `.matches()`, leading to the crash.
2. No deletion of the character to the left of the cursor
`DeletePlugin.isVisibleChar` handles the edge cases where backspace is pressed while the cursor is positioned to the side of a button, and defines the visibility of Zwnbsp to determine how much is deleted. The padding Zwnbsp to the left of a button are considered as visible, such that the user can delete an empty button without removing also the first character on its left. Anyway, the current code does not actually check if the button is empty, thus it applies to more cases than necessary. Probably this has never been observed before, because it takes a very precise click to the left edge to position the cursor between a button and its left Zwnbsp.

**Fix**
1. Prevent the crash in `LinkPlugin`
`LinkPlugin.handleDeleteBackward` now ensures that `previousSibling` is an element node before calling `matches`, otherwise it returns.
2. Fix backspace behavior in `DeletePlugin`
`deletePlugin.isVisibleChar` now considers as visible only the Zwnbsp positioned to the left of an empty button. This way, if the user clicks on the very left edge of a button (which moves the cursor outside the button, to the left), pressing backspace actually deletes the character on the left.

task-6102282

Forward-Port-Of: odoo/odoo#258858

Currently, an error occurs when a user attempts to mark a payslip as paid.

**Steps to Reproduce:**

 - Install the `hr_payroll` module without demo data.
 - Go to `Payslips` and click on `New Off-cycle`.
 - Create a record > `Compute` > `Validate`, and Pay.
 - In the wizard, enable `Include Unpaid` and select `CSV` mode.
 - Click `Mark as Paid`.

**Error:**
`UnboundLocalError: cannot access local variable 'rows' where it is not associated with a value`

The error occurs when a user tries to mark a payslip as paid with Include Unpaid enabled. 
When the wizard is created from here [1], the default unpaid payslips are empty. In this case, 
the system assigns an empty set of payslips to process [2].and the rows variable is not 
defined because there are no payslips to work on, which raises the error [3].

This commit ensures that when the wizard is created, the matched unpaid payslips are passed to 
the wizard. If the Include Unpaid option is enabled, the unpaid payslips are assigned for processing, 
similar to [4]. The unpaid payslips cannot be empty, as they always include the currently 
processed payslip.
Also, the rows are redefined for each payslip case and updated accordingly. Therefore, this commit 
ensures that the rows are created at the end from grouped payments.

[1] https://github.com/odoo/enterprise/blob/a784d118e076724b02e5c59d9ce5d1815c42b0bf/hr_payroll/models/hr_payslip.py#L792-L809

[2] https://github.com/odoo/enterprise/blob/e971fca0d09e564ae9029f3d7e166e078c44dcbb/hr_payroll/wizard/hr_payroll_payment_report_wizard.py#L56

[3] https://github.com/odoo/enterprise/blob/e971fca0d09e564ae9029f3d7e166e078c44dcbb/hr_payroll/wizard/hr_payroll_payment_report_wizard.py#L97

[4]: https://github.com/odoo/enterprise/blob/a784d118e076724b02e5c59d9ce5d1815c42b0bf/hr_payroll/models/hr_payslip_run.py#L274-L288

sentry-7436885639

Forward-Port-Of: odoo/enterprise#115090

Issue
-----
Putting a max weight on a package type causes getting a rate with Sendcloud to fail.

Steps to reproduce
-----
- Setup Mondial Relay using Sendcloud
- Set a default package type with max weight 2kg
- Create a product with a 500g weight
- Create a SO with the product
- Add delivery
	- Sendcloud Mondial Relay
	- Get rate

> Impossible to get a rate

Cause
-----
When retrieving the shipping method to use when retrieving a rate, we use the real weight of the order.

https://github.com/odoo/enterprise/blob/cca1433f5a064673b8e007530e20e8a9fe72949b/delivery_sendcloud/models/sendcloud_service.py#L67 https://github.com/odoo/enterprise/blob/cca1433f5a064673b8e007530e20e8a9fe72949b/delivery_sendcloud/models/sendcloud_service.py#L81

However, when making the rate call, we use the value returned by `_split_shipping`

https://github.com/odoo/enterprise/blob/cca1433f5a064673b8e007530e20e8a9fe72949b/delivery_sendcloud/models/sendcloud_service.py#L91

which is equal to the maximum weight of the package. This is blocking in some cases, like if
- the real weight is 750g
- the package max is 2kg
- Sendcloud returns a shipping method for [500g;1kg]

Asking a rate for this method & a 2kg package will fail (rightfully so).

Solution
-----
The shipment should be split into packages before retrieving the shipping methods. Otherwise the problem might be the other way around where we retrieve a shipping method for the whole order, only to split it into multiple packages because they don't fit in one.

Also, the `shipping_weight` returned by `_split_shipping` should only be different from the order's total weight if it is higher than the maximum deliverable weight.

-----
Ticket:
opw-5947199

Forward-Port-Of: odoo/enterprise#116415
Forward-Port-Of: odoo/enterprise#108315

### Steps to reproduce:

- In the settings Enable: "Multi-Steps Routes"
- Unarchive the MTO route
- Create a storable product with MTO enabled and a set vendor
- Create and confirm two sale orders for 1 unit of that product
- Go to the purchase order view, select both PO > Actions > Merge RFQs
#### > The un-cancelled Purchase order is  only linked to one of the 2 SOs

### Cause of the issue:

The sale orders linked to a PO in this flow are linked through the stock references:
https://github.com/odoo/odoo/blob/fb79136e259e2b56746afda64b2536bddf6755c0/addons/sale_purchase/models/purchase_order.py#L60-L61 https://github.com/odoo/odoo/blob/fb79136e259e2b56746afda64b2536bddf6755c0/addons/sale_purchase_stock/models/purchase_order.py#L14-L15 However, the references of the PO merged to the present one are not merged as well.

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

Forward-Port-Of: odoo/odoo#263371
Forward-Port-Of: odoo/odoo#261578

**Steps to reproduce:**

- Download the German language
- Set the restaurant to QR + Ordering
- Set the Service at Table, pay after each order
- Set the language to German
- Go to the Self and order something while the language is German
- Chose table 12
- Go to the kitchen display
- The title is truncated, meaning we can't see the table number

**Why the fix:**

If the title is more than 150px it will be truncated and "..." will replace the table number. This has been introduced in 
ed5b010dc7b5c11bbbc8513c1edb0ec4f58778c1 but not being able to see the table number might be bad as some people would need to spend time trying to figure out which table the order is for, instead of just having to look at the kitchen display.

We now revert this change to break to a new line in the case where the card title is too long, so we can always see the table number.

Before:
<img width="317" height="156" alt="image" src="https://github.com/user-attachments/assets/25e76026-bdad-4639-9dfc-0d75ffa8d8c8" />

Afer:
<img width="329" height="174" alt="image" src="https://github.com/user-attachments/assets/f387dd5f-96d3-4148-bc76-215393c76e67" />


opw-6096111

Forward-Port-Of: odoo/enterprise#114859

### Steps to reproduce:

- In the settings enable "Packages"
- Create a storable product A and put 1 unit in a package P in stock
- Inventory > Products > Packages > open your package P
- Set a parent package PP as container
- Inventory > Operations > Adjustments > Physical Inventory
- Select you product line for A > Request a count (from the control panel button)
- Enable Show Expected Quantity and confirm
- Go to the barcode app > Count Inventory (1)
- scan your parent package PP
#### > traceback: Uncaught Promise > Cannot create property 'inventory_quantity' on boolean 'false'

### Cause of the issue:

When the Package scan is processed, we loop over all quants related to it:
https://github.com/odoo/enterprise/blob/30a28e28f8dd27cf2c88df65e5ff47eab59360c7/stock_barcode/static/src/models/barcode_quant_model.js#L566-L569 https://github.com/odoo/enterprise/blob/30a28e28f8dd27cf2c88df65e5ff47eab59360c7/stock_barcode/static/src/models/barcode_quant_model.js#L602-L617
And for each of these we try to find an existing line representing the quant to update or we do create a new line. Now, the issue, is that the subpackages of the quant are not provided to find the quant candidate line to update. As such, no line is found we enter the else clause and try to createa a NewLine:
https://github.com/odoo/enterprise/blob/30a28e28f8dd27cf2c88df65e5ff47eab59360c7/stock_barcode/static/src/models/barcode_quant_model.js#L617-L627 This time however, the appropriate subpackage (the one of the quant) is provided to the arguments. And, since the line representing this quant is already existing, the `_createNewLine` will return False: https://github.com/odoo/enterprise/blob/30a28e28f8dd27cf2c88df65e5ff47eab59360c7/stock_barcode/static/src/models/barcode_quant_model.js#L393-L399 https://github.com/odoo/enterprise/blob/30a28e28f8dd27cf2c88df65e5ff47eab59360c7/stock_barcode/static/src/models/barcode_quant_model.js#L423
This leads to a traceback at the end of the else close since `false.inventory_quantity` doe not make sense (Cannot create property 'inventory_quantity' on boolean 'false') https://github.com/odoo/enterprise/blob/30a28e28f8dd27cf2c88df65e5ff47eab59360c7/stock_barcode/static/src/models/barcode_quant_model.js#L626-L627

Fix:

We adapt the `_processPackage` of the `BarcodeQuantModel` to mimic the existing 'update' behavior on the `BarcodePickingModel`: https://github.com/odoo/enterprise/blob/30a28e28f8dd27cf2c88df65e5ff47eab59360c7/stock_barcode/static/src/models/barcode_picking_model.js#L2110-L2133
Note that UOM converstion should not be required since quants are already uniformly expressed in the product uom:
https://github.com/odoo/odoo/blob/30b4edace6b0859cb1b1ba4f7f2ea80ba5398e3d/addons/stock/models/stock_quant.py#L52-L54

opw-5864591

Forward-Port-Of: odoo/enterprise#116715

**Steps to reproduce:**

Problem A)
- create a storable product avco perpetual
- add 2 unit in stock and set a cost of 10
- set the invoicing policy as "delivered quantities"
- create and confirm a SO for 2 quantities
- validate the delivery
- click on "Create Invoice" and confirm the invoice
- from the delivery, create and validate a return for 1 unit.
- from the product form, change the cost to 15
- from the sale order, click on "Create Invoice"
- confirm the Credit Note

Problem B)
- create a storable product with fifo perpetual
- confirm a PO for 1 unit at 10 and validate receive
- confirm a PO for 1 unit at 20 and validate receive
- confirm a PO for 1 unit at 60 and validate receive
- create a SO for 3 unit
- deliver 1 unit with backorder
- deliver another unit with backorder
- deliver the last unit
- create and confirm invoice
- return the second delivery
- from the invoice click on 'credit note' and validate
the credit note with a quantity of 1

**Current behavior:**

Problem A)
the cogs is 25

Problem B)
the cogs is 30

**Expected behavior:**

Problem A)
it should be 10

Problem B)
the cogs should be 20 cause the move returned
had a value of 20

**Cause of the issue:**
Inside \_get\_cogs_value(), if there is an original invoice
linked to the credit note we take the unit_price from this invoice.
But, if the credit note is not created from the invoice (via the
Credit Note button) but via the sale order (via create invoices),
the account\_move has no reverse\_entry_id so we won't
use the price_unit from the original line.
https://github.com/odoo/odoo/blob/686a0cf67bb1e818baf43309fc94f3f0462097ed/addons/stock_account/models/account_move_line.py#L56-L58
So basically what we do for now is:
If the credit note was created from invoice we use
the unit price from original invoice in all cases.
If the credit note was created from sale order we
use get\_price\_unit in all cases (which will work for
fifo because we'll use the value of the returned
move but fail for avco if the standard price has
changed cause we use the standard price)
https://github.com/odoo/odoo/blob/dccd2256660b1e211707b740074f5fbba95ae149/addons/stock_account/models/stock_move.py#L261-L265

**Fix:**
Regardless of how the credit note is created, if
it's fifo we use get\_price\_unit to adapt to the value
of the moves, if not we use the unit_price from
original invoice

opw-6097090

Forward-Port-Of: odoo/odoo#259630

Steps to reproduce
------------------
1. Create a sale order with 2 products, confirm it
2. Cancel the SO, then click "Set to Quotation"
3. Open PoS, settle the order and pay
4. Check the delivery order linked to the PoS order

The delivery is empty, yet the products still show as "delivered" on
the sale order.

Why it's happening
------------------
When the SO is cancelled, its moves go to 'cancel' state. After
resetting to quotation, those moves stay cancelled. When PoS creates
the delivery, the filter in `_create_move_from_pos_order_lines` checks
`has_valued_move_ids()` which returns False (all moves are cancelled),
and `not move_ids` is also False (cancelled moves still exist). So the
lines coming from the SO are excluded from the delivery.

The fix
-------
We now also create deliveries for lines whose SO moves are all
cancelled. These are lines coming from a cancelled SO that now need
to be shipped after we have settled their order from PoS.

Note
----
The commit c0f338711f028088c98ea459f27c1669b29738d7 fixes this starting from saas-18.2, by introducing a separate `pos_repair` module which simplifies the main `pos_sale` code. In 18.2+, only the test will be forward ported.

opw-6055856

Forward-Port-Of: odoo/odoo#263917
Forward-Port-Of: odoo/odoo#256693

FIX] purchase_stock: handle missing seller during PO line update (min_qty)
**Steps to Reproduce:**

- Install Sale, Inventory, Manufacturing, and Purchase.
- Enable MTO, Units of Measure, and Routes.
- Create a product:
      Set a vendor price with min_qty = 1.0.
      Enable MTO route.
     Add a BoM with a component product.
    Set quantity to 0.1 (less than vendor min_qty).
- Create a Sale Order with the same product added twice.
- Confirm the Sale Order.

**Issue:**
During procurement:

- First procurement correctly fetches the supplier.
- On PO line update (_update_purchase_order_line), seller is recomputed.
  Due to min_qty filtering, no seller is returned when quantity is low.
  This results in: Missing seller, Missing product_uom, Invalid price
  computation, And finally causes a crash when confirming the Purchase Order,
  in _get_stock_move_price_unit: ZeroDivisionErroR

Root Cause:

- _select_seller filters suppliers using min_qty.
 During merge/update flow, recomputed quantity may not satisfy min_qty.
 Existing valid supplier (from initial procurement) is ignored.
 No fallback handling in _update_purchase_order_line.

**Solution:**

- Add fallback logic when _select_seller returns no result: Use
  _prepare_sellers() to fetch a valid supplier ignoring min_qty.
- Ensure a supplier is always available for: UoM resolution, Price computation
   Prevents crash and ensures consistent PO line updates.

**Result:**

- No traceback when quantity < vendor min_qty
  Supplier, UoM, and price are properly set

**OPW-6106487**

Forward-Port-Of: odoo/odoo#263699
Forward-Port-Of: odoo/odoo#259894

## Issue
When opening the *Hierarchy* view of Employees > Departments, if at least one department has a manager set, a traceback appears before the view.

## Steps to reproduce
1. Install *Employees* (`hr`)
2. In Employees > Departments, add a manager to a department
3. Open the *Hierarchy* view
4. **A traceback appears:**

```
Caused by: TypeError: Cannot read properties of undefined (reading 'toMillis')
    at get uniqueId (http://localhost:8192/web/assets/cbd2032/web.assets_web.min.js:21370:74)
    at Many2OneAvatarEmployeeField.template (eval at compile (http://localhost:8192/web/assets/cbd2032/web.assets_web.min.js:1387:421), <anonymous>:25:122)
...
```

## Cause
The traceback is yielded from the `get uniqueId` getter from the `Many2OneAvatarEmployeeField` component:

https://github.com/odoo/odoo/blob/c3172d65db44c41f5619aef20532c3846494ea0e/addons/hr/static/src/views/fields/many2one_avatar_employee_field/many2one_avatar_employee_field.js#L38-L40

where `write_date` is undefined. This getter was added by https://github.com/odoo/odoo/commit/3732ca85b03bea9eabfb05cc306ce0bf5bac88d4, which handled the case of undefined `write_date` for the related Kanban component:

https://github.com/odoo/odoo/blob/c3172d65db44c41f5619aef20532c3846494ea0e/addons/hr/static/src/views/fields/many2one_avatar_employee_field/kanban_many2one_avatar_employee_field.js#L49-L52

A similar solution is applied in this problematic getter.

opw-6128837

**Description of the problem**
Pressing backspace when the cursor is positioned at the very left edge of a button could trigger a traceback. Additionally, even if the crash did not occur, the backspace behavior would be incorrect, because the cursor would move across a zero-width non-breaking space (Zwnbsp) without deleting the first character to the left.

**How to reproduce**
In the `html_editor`, create a button. Click on its very left edge, then press backspace. An error is thrown.

**Why the problem happens**
1. Traceback when backspace is pressed
`LinkPlugin.handleDeleteBackward` assumes that `previousSibling` is an element node, and calls the `matches` method. However, when clicking on the very left edge of a button, the cursor is positioned such that the left sibling (`previousSibling`) is a text node. Text nodes do not implement `.matches()`, leading to the crash.
2. No deletion of the character to the left of the cursor
`DeletePlugin.isVisibleChar` handles the edge cases where backspace is pressed while the cursor is positioned to the side of a button, and defines the visibility of Zwnbsp to determine how much is deleted. The padding Zwnbsp to the left of a button are considered as visible, such that the user can delete an empty button without removing also the first character on its left. Anyway, the current code does not actually check if the button is empty, thus it applies to more cases than necessary. Probably this has never been observed before, because it takes a very precise click to the left edge to position the cursor between a button and its left Zwnbsp.

**Fix**
1. Prevent the crash in `LinkPlugin`
`LinkPlugin.handleDeleteBackward` now ensures that `previousSibling` is an element node before calling `matches`, otherwise it returns.
2. Fix backspace behavior in `DeletePlugin`
`deletePlugin.isVisibleChar` now considers as visible only the Zwnbsp positioned to the left of an empty button. This way, if the user clicks on the very left edge of a button (which moves the cursor outside the button, to the left), pressing backspace actually deletes the character on the left.

task-6102282

Forward-Port-Of: odoo/odoo#258858

## Issue
When generating a DMFA report with a working schedule with more or less than 5 days a week, the *Days Per Week* value in the report is still appearing as 5.

## Steps to reproduce
1. Install *Belgium - Payroll* (`l10n_be_hr_payroll`)
2. In Payroll's Settings:
    - set *ONSS Registration Number* to `0830123456`
    - set *DMFA Employer Class* to `083`
    - create a *Work Address DMFA code* (any name, any numeral code, but set the *Working Address* to the Belgian company used for the rest of the steps)
3. In Employees' Settings, set the *Company Working Hours* to a new Working Schedule, with 9 hours/day, 4 days/week. E.g from Monday to Thursday included:
    - Work from 8:00 to 12:00
    - Lunch from 12:00 to 13:00
    - Work from 13:00 to 18:00
4. Create an Employee E for the Belgian company:
    - In the *Payroll* tab, set the start date of the contract to 01/01/2026.
    - In the *Personal* tab, set the *NISS Number* to `85073003328`
5. Create the payslip for January 2026 for the Employee E.
6. In Payroll > Reporting > Belgium > DMFA, create a new DMFA for the first quarter of 2026 and generate the PDF report
7. **In the generated PDF report, the _Days per Week_ line is set to 5.**

## Cause
The number of days was calculated by multiplying `5` with the `work_time_rate` of the related calendar. This is inaccurate in the case of a company where employees are only expected to work 4 days a week.

opw-6103934

Forward-Port-Of: odoo/enterprise#116794
Forward-Port-Of: odoo/enterprise#113804

**Steps-to-Reproduce**
- In v19, install subscriptions.
- create new subscription + service product with allow one time sale enabled.
- make a SO with that product,any reccuring plan and any end date. 
```
id |  name  | subscription_state | next_invoice_date |  end_date  
----+--------+--------------------+-------------------+------------
  1 | S00001 | 1_draft            |                   | 2026-05-02
```

- confirm the SO
```
 id |  name  | subscription_state | next_invoice_date |  end_date  
----+--------+--------------------+-------------------+------------
  1 | S00001 | 3_progress         | 2026-05-01        | 2026-05-02
```
- remove its recurring plan (some product sold for months for testing then converted to one time sale )
```
 id |  name  | subscription_state | next_invoice_date |  end_date  
----+--------+--------------------+-------------------+------------
  1 | S00001 | 3_progress         |                   | 2026-05-02
```

- upgrade to v19.1 will fail or opening sales > To Invoice > Orders To Invoice gives this error or add amount_to_invoice in list view using studio to produce in v19 :
```
File "/home/odoo/odoo18/enterprise/sale_subscription/models/sale_order_line.py",
 line 175, in _compute_amount_to_invoice
    and (not order.end_date or order.next_invoice_date < order.end_date)
                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: '<' not supported between instances of 'bool' and 'datetime.date'
```

- upgrade failing for v19.1 because amount_to_invoice added to list view [here](https://github.com/odoo/odoo/commit/427232efd121410380b62acf4fd2e9ee369e6542#diff-48cb4309a6006f91b2b40e4c1049860218d419fce1782c7dcc278329803129caR193-R213).

upg - [4220658](https://upgrade.odoo.com/odoo/upgrade.request/4220658)
opw - [6128033](https://www.odoo.com/odoo/project/70/tasks/6128033)

Forward-Port-Of: odoo/enterprise#115976

Steps to reproduce
------------------
1. Create a sale order with 2 products, confirm it
2. Cancel the SO, then click "Set to Quotation"
3. Open PoS, settle the order and pay
4. Check the delivery order linked to the PoS order

The delivery is empty, yet the products still show as "delivered" on
the sale order.

Why it's happening
------------------
When the SO is cancelled, its moves go to 'cancel' state. After
resetting to quotation, those moves stay cancelled. When PoS creates
the delivery, the filter in `_create_move_from_pos_order_lines` checks
`has_valued_move_ids()` which returns False (all moves are cancelled),
and `not move_ids` is also False (cancelled moves still exist). So the
lines coming from the SO are excluded from the delivery.

The fix
-------
We now also create deliveries for lines whose SO moves are all
cancelled. These are lines coming from a cancelled SO that now need
to be shipped after we have settled their order from PoS.

Note
----
The commit c0f338711f028088c98ea459f27c1669b29738d7 fixes this starting from saas-18.2, by introducing a separate `pos_repair` module which simplifies the main `pos_sale` code. In 18.2+, only the test will be forward ported.

opw-6055856

Forward-Port-Of: odoo/odoo#263917
Forward-Port-Of: odoo/odoo#256693

### Steps to reproduce:

- In the settings enable "Packages"
- Create a storable product A and put 1 unit in a package P in stock
- Inventory > Products > Packages > open your package P
- Set a parent package PP as container
- Inventory > Operations > Adjustments > Physical Inventory
- Select you product line for A > Request a count (from the control panel button)
- Enable Show Expected Quantity and confirm
- Go to the barcode app > Count Inventory (1)
- scan your parent package PP
#### > traceback: Uncaught Promise > Cannot create property 'inventory_quantity' on boolean 'false'

### Cause of the issue:

When the Package scan is processed, we loop over all quants related to it:
https://github.com/odoo/enterprise/blob/30a28e28f8dd27cf2c88df65e5ff47eab59360c7/stock_barcode/static/src/models/barcode_quant_model.js#L566-L569 https://github.com/odoo/enterprise/blob/30a28e28f8dd27cf2c88df65e5ff47eab59360c7/stock_barcode/static/src/models/barcode_quant_model.js#L602-L617
And for each of these we try to find an existing line representing the quant to update or we do create a new line. Now, the issue, is that the subpackages of the quant are not provided to find the quant candidate line to update. As such, no line is found we enter the else clause and try to createa a NewLine:
https://github.com/odoo/enterprise/blob/30a28e28f8dd27cf2c88df65e5ff47eab59360c7/stock_barcode/static/src/models/barcode_quant_model.js#L617-L627 This time however, the appropriate subpackage (the one of the quant) is provided to the arguments. And, since the line representing this quant is already existing, the `_createNewLine` will return False: https://github.com/odoo/enterprise/blob/30a28e28f8dd27cf2c88df65e5ff47eab59360c7/stock_barcode/static/src/models/barcode_quant_model.js#L393-L399 https://github.com/odoo/enterprise/blob/30a28e28f8dd27cf2c88df65e5ff47eab59360c7/stock_barcode/static/src/models/barcode_quant_model.js#L423
This leads to a traceback at the end of the else close since `false.inventory_quantity` doe not make sense (Cannot create property 'inventory_quantity' on boolean 'false') https://github.com/odoo/enterprise/blob/30a28e28f8dd27cf2c88df65e5ff47eab59360c7/stock_barcode/static/src/models/barcode_quant_model.js#L626-L627

Fix:

We adapt the `_processPackage` of the `BarcodeQuantModel` to mimic the existing 'update' behavior on the `BarcodePickingModel`: https://github.com/odoo/enterprise/blob/30a28e28f8dd27cf2c88df65e5ff47eab59360c7/stock_barcode/static/src/models/barcode_picking_model.js#L2110-L2133
Note that UOM converstion should not be required since quants are already uniformly expressed in the product uom:
https://github.com/odoo/odoo/blob/30b4edace6b0859cb1b1ba4f7f2ea80ba5398e3d/addons/stock/models/stock_quant.py#L52-L54

opw-5864591

Forward-Port-Of: odoo/enterprise#116715

Issue:
----------------------------------------
When having an employee with `l10n_us_filing_status` not in `['single', 'jointly']` and evaluating the rule parameter `l10n_us_qualified_overtime_deduction_cap` an error occurs.

Cause:
----------------------------------------
`l10n_us_filing_status` can have 5 values: `['single', 'jointly', 'separately', 'head', 'survivor']` But only `['single', 'jointly']` are defined for `l10n_us_qualified_overtime_deduction_cap` ([src](https://github.com/odoo/enterprise/blob/2d2056766441157dc45ebc37b677841c44e5c513/l10n_us_hr_payroll/data/hr_rule_parameters_data.xml#L48)).

When running the rule "Qualified Overtime", the custom Python crashes because we read a key that is not there:

https://github.com/odoo/enterprise/blob/2d2056766441157dc45ebc37b677841c44e5c513/l10n_us_hr_payroll/data/hr_salary_rule_data.xml#L56

Solution:
----------------------------------------
In the custom Python condition, we first check if the key is there.

The custom Python computation also tries to read the key, but it is run only if the condition is validated. So we don't need to change it.

Also fixed indentation of test 069.

opw-6129657

Forward-Port-Of: odoo/enterprise#116551
Forward-Port-Of: odoo/enterprise#115754

#### Issue:
Clicking `Unassign` from the stock reception report could raise a traceback
when the outgoing move source document was empty.
``ValueError: Expected singleton: mrp.production()``

Please note that this is not expected in standard Odoo, where reception report moves
should normally be linked to a source document, such as an MO, SO, or picking.

This case seems specific to the client database and may be due to a customization, but handling it makes the reception report more robust.
#### Cause:
The reception report built report lines from `source = (move._get_source_document(),)`
and checked `if not source`. Since the tuple itself is truthy, moves whose
`_get_source_document()` returned an empty recordset were not filtered out.

For example if `out_move._get_source_document()` returns `mrp.production()`, then
`source = (mrp.production(),)` is still truthy, so the report keeps the line
even though the source document is empty.

later `action_unassign()` called `_remove_reference()` on that empty source
document, which crashed on `ensure_one()`.

#### Fix:
Added a helper function that skips moves where `_get_source_document()` is empty.
Also skip reference synchronization in `_action_assign()` and `_action_unassign()`
when the source document is empty just for more protection.

opw-6174870

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

Forward-Port-Of: odoo/odoo#263366

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

Issue
-----
Forced full packaging reservation setting is ignored when there is a big quant in stock.

Steps to reproduce
-----
- Enable packagings
- Create a product category "Super Category"
    - Reserve Packagings: Reserve Only Full Packagings
- Create a stored product "AAA"
    - Product Category: Super Category
    - 50 units on hand
    - Packaging: 6-Pack (6 units)
- Create a delivery for 15 units of AAA

> Reservation is made for 15 units

Cause
-----
The rounding to a multiple of the packaging quantity takes the stock quant into account. For our example case, we have 8 full 6-Packs on hand, so the `available_quantity` gets set to 48 when doing

https://github.com/odoo/odoo/blob/5e458236ca2ff2ab92c4893495e7a721be902c40/addons/stock/models/stock_quant.py#L923-L925

This leads to the reservation quantity being min(15, 48) = 15

https://github.com/odoo/odoo/blob/5e458236ca2ff2ab92c4893495e7a721be902c40/addons/stock/models/stock_quant.py#L927

-----
Ticket:
opw-5974333

Forward-Port-Of: odoo/odoo#263114
Forward-Port-Of: odoo/odoo#257342

Issue
-----
When there are 2 lines for a single product and different packaging uoms, scanning a packaging barcode alternates between lines.

Steps to reproduce
-----
- Enable packagings
- Create a product AAA
	- barcode 1
- Create a packaging 6-Pack
	- 6 units
	- barcode for AAA set to 6
- Create a PO
	- one line for 30 units of AAA
	- one line for 5 6-Pack of AAA
- Confirm PO and open picking in barcode
- Scan "6" multiple times

> Quantity increases on both lines, alternating for each scan

Cause
-----
Both lines can be found as matching lines when doing

https://github.com/odoo/enterprise/blob/d279632db25713dd639a51385cad197dfdbd2bdc/stock_barcode/static/src/models/barcode_model.js#L1426

The reason it alternates between the lines is because we set the currently selected line first in the array - and since both lines match, the `foundLine` returned ends up being the non-selected line.

https://github.com/odoo/enterprise/blob/d279632db25713dd639a51385cad197dfdbd2bdc/stock_barcode/static/src/models/barcode_model.js#L1823-L1832

We can avoid this y refining the `break` condition of the loop to also match the packaging uom.

-----
Ticket:
opw-6034572

Forward-Port-Of: odoo/enterprise#112578

### Steps to reproduce:

- In the settings enable "Packages"
- Create a storable product A and put 1 unit in a package P in stock
- Inventory > Products > Packages > open your package P
- Set a parent package PP as container
- Inventory > Operations > Adjustments > Physical Inventory
- Select you product line for A > Request a count (from the control panel button)
- Enable Show Expected Quantity and confirm
- Go to the barcode app > Count Inventory (1)
- scan your parent package PP
#### > traceback: Uncaught Promise > Cannot create property 'inventory_quantity' on boolean 'false'

### Cause of the issue:

When the Package scan is processed, we loop over all quants related to it:
https://github.com/odoo/enterprise/blob/30a28e28f8dd27cf2c88df65e5ff47eab59360c7/stock_barcode/static/src/models/barcode_quant_model.js#L566-L569 https://github.com/odoo/enterprise/blob/30a28e28f8dd27cf2c88df65e5ff47eab59360c7/stock_barcode/static/src/models/barcode_quant_model.js#L602-L617
And for each of these we try to find an existing line representing the quant to update or we do create a new line. Now, the issue, is that the subpackages of the quant are not provided to find the quant candidate line to update. As such, no line is found we enter the else clause and try to createa a NewLine:
https://github.com/odoo/enterprise/blob/30a28e28f8dd27cf2c88df65e5ff47eab59360c7/stock_barcode/static/src/models/barcode_quant_model.js#L617-L627 This time however, the appropriate subpackage (the one of the quant) is provided to the arguments. And, since the line representing this quant is already existing, the `_createNewLine` will return False: https://github.com/odoo/enterprise/blob/30a28e28f8dd27cf2c88df65e5ff47eab59360c7/stock_barcode/static/src/models/barcode_quant_model.js#L393-L399 https://github.com/odoo/enterprise/blob/30a28e28f8dd27cf2c88df65e5ff47eab59360c7/stock_barcode/static/src/models/barcode_quant_model.js#L423
This leads to a traceback at the end of the else close since `false.inventory_quantity` doe not make sense (Cannot create property 'inventory_quantity' on boolean 'false') https://github.com/odoo/enterprise/blob/30a28e28f8dd27cf2c88df65e5ff47eab59360c7/stock_barcode/static/src/models/barcode_quant_model.js#L626-L627

Fix:

We adapt the `_processPackage` of the `BarcodeQuantModel` to mimic the existing 'update' behavior on the `BarcodePickingModel`: https://github.com/odoo/enterprise/blob/30a28e28f8dd27cf2c88df65e5ff47eab59360c7/stock_barcode/static/src/models/barcode_picking_model.js#L2110-L2133
Note that UOM converstion should not be required since quants are already uniformly expressed in the product uom:
https://github.com/odoo/odoo/blob/30b4edace6b0859cb1b1ba4f7f2ea80ba5398e3d/addons/stock/models/stock_quant.py#L52-L54

opw-5864591

Forward-Port-Of: odoo/enterprise#116715

When the network drops after eTIMS processes a transaction but before Odoo receives the confirmation, Odoo would retry with the same invoice number, causing eTIMS error 924 (Invoice number already exists).

For POS orders, the old code decremented the sequence on any error (including timeout), so the next retry consumed the same invcNo. If eTIMS had already recorded the original send, the retry was rejected with 924. Fix by introducing a fetch-first strategy: on retry, if a pending invcNo is found in l10n_ke_order_json, call selectInvoiceDetails before sending. If eTIMS already has the invoice, recover the receipt data directly without resending. If eTIMS does not have it, resend with the same invcNo safely. On timeout errors, the sequence is no longer decremented so the invcNo is preserved in l10n_ke_order_json for the next idempotent retry.

For customer invoices, the existing fetch-first logic only bailed out on TIM (timeout) errors, falling through on CON (connection) errors and retrying blindly. Additionally, if saveTrnsSalesOsdc returned 924, there was no recovery path and the invoice number would be cleared. Fix by also bailing on CON in the fetch block, and adding an explicit 924 handler that calls selectInvoiceDetails to recover the existing receipt instead of failing.

opw-6105693

## Issues
When starting a timer from a task within a project, the timer appears in two locations: the page header, and the task's *Timesheets* tab. The latter does not behave as expected: when opening the *Timesheets* tab,
the timer resets to 00:00, and if the timer was started more than a minute earlier, it begins counting down (00:00, then -00:59, and so on). (**I1**)

A second issue (**I2**), introduced at the same time, is that two timers can run simultaneously if the database is reloaded while a timer is active.

A third issue (**I3**) happens after starting and stopping a timer from the Project app: the timer seems to still be running in the Timesheet app.

## Steps to reproduce
1. Install *Timesheets* (`timesheet_grid`)
2. Create a Project P and a Task T
3. Start the timer for Task T, wait a few seconds, then open the *Timesheets* tab
4. **The timer from the _Timesheets_ tab does not match the one on top of the page**
5. Wait for the timer in the header to reach 00:01:00, then open the *Timesheets* tab again
6. **The timer is going backward**

For the second issue (**I2**), after executing the steps above:
7. Do not stop the timer, but stop the database and start it again
8. Create a new Project P2 and a Task T2
9. Start the timer for Task T2
10. **The timer in the header blinks between the timer from T1 and the newly started timer for T2**

![5879176](https://github.com/user-attachments/assets/d9be8b8c-8973-4790-80a5-6f291f0b766a)

For the third issue (**I3**):
1. In the project app, (create a project and a task and) start then stop a timer. Log the time
2. Open the timesheet app
3. **A timer is running**

## Cause
The issues are introduced by the following commit: https://github.com/odoo/enterprise/commit/f4c7115fdf.
The commit aimed to resolve an issue in which timers for sample data would start automatically, and the *Stop* button would throw an error. The issue was addressed by updating the condition that defines the `timerRunning`
variable, which controls whether the *Stop* button in the Timesheets app is displayed.

https://github.com/odoo/enterprise/blob/ac186aa71cd7e1b80b307ea12c7eaca246afd649/timesheet_grid/static/src/components/timesheet_display_timer/timesheet_display_timer.js#L57-L64

Issue **I1** is a side effect of this change in the Project app, where the `timerRunning` variable is evaluated to `true`, causing the timer to be displayed when it should not.

The multiple timers running simultaneously (**I2**) stems from the `timerRunning` variable being initiated to false by default in the props.

https://github.com/odoo/enterprise/blob/64f813dab727d76286c1ff6c80c08cb6a6737b49/timesheet_grid/static/src/components/timesheet_display_timer/timesheet_display_timer.js#L47-L50

The *Stop* button appearing after logging a task (**I3**) stems from the condition of the patch using `is_timer_running` over `timer_start`.

https://github.com/odoo/enterprise/blob/64f813dab727d76286c1ff6c80c08cb6a6737b49/timesheet_grid/static/src/hooks/sample_server_patch.js#L9-L15

## Fix
This commit reverts the problematic segments from the previous commit.

opw-5870756
opw-5879176
opw-5961764

Forward-Port-Of: odoo/enterprise#107014

__

## Short functional explanation of the error
When we have a subscription product that has already been sold. If we try to import a product with the same ID but where we change the subscription type of the product, the import is executed without issue. However, this leads to undesired behavior:
when we go to the product page and try to manually change the subscription type (set it back to subscription), the change is not applied as a warning is raised.

## Reproduction Steps
Make sure you have debug mode enabled.
1. Create a product, and check the Subscription box.
2. Click on Orders and create a Quotation with this product, then confirm.
3. Go to Products > Products. Select the list view and search for the product you just created. Select it, and click Actions > Export.
4. Check the import compatible field. Select the fields to export: name, id and recurring_invoice. Upon exporting, a file is downloaded.
5. Access that file and change the recurring_invoice to FAUX or FALSE if your computer is in English. Save the changes.
6. Unselect the product and click on the cog, top right > Import. Click on Upload Data File and select the file that you have downloaded upon exporting, then import.

### Expected behavior
A user warning is raised: we shouldn't be able to change the subscription type of the product when it has already been sold.

### Unexpected behavior
The import is processed normally. Then, when we access the product page, and try to check the Subscriptions box again, a warning is raised.

## Origin of the issue
Nothing prevents the import from occurring in that case.

__
opw-6143789

Forward-Port-Of: odoo/enterprise#116922
Forward-Port-Of: odoo/enterprise#115046

Steps to reproduce
1. Open the Barcode app > Operations > Delivery Orders.
2. Switch to the "Batches" tab.
3. Create a new one.

Issue
The created batch keeps the placeholder name "New" instead of being
renamed to `BATCH/<TYPE>/000NN`.

The barcode kanban "New" button calls `open_new_batch_picking`, which
runs `Batch.create({})` while the action context carries
`default_picking_type_id` set by `stock.picking.type._get_action` at
https://github.com/odoo/odoo/blob/f768f276171b079a76324d40307db385f558dda6/addons/stock/models/stock_picking.py#L432.
Since `vals` itself doesn't carry `picking_type_id`, the lookup in
`stock.picking.batch.create()` at
https://github.com/odoo/odoo/blob/f768f276171b079a76324d40307db385f558dda6/addons/stock_picking_batch/models/stock_picking_batch.py#L181
returns an empty recordset, so the sequence-based rename branch is
skipped and the name stays at the field default `'New'`. The
subsequent `super().create` then applies the context default, so the
batch is correctly linked to a picking type but with the wrong name.

opw-6168320

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#111304

Before commit:
The Norwegian VAT XML export fails Skatteetaten validation due to incorrect
decimal formatting, mathematical rounding mismatches between base and tax
amounts, missing mandatory legal notes, and invalid KID number formats.

Fix:
To strictly follow Skatteetaten validation rules for the Norway VAT XML, the
following changes were implemented:
- Ensured standard rates drop the decimal (e.g, `25.0` to `25`), and formatted 
  fractional rates like `11.11` to `11,11` in XML.
- Rounded down the `tax_amount` to align precisely with government mathematical
  expectations.
- `base_amount` converted into absolute value to ensuring the calculation
  (`base * rate = tax`) resolves perfectly.
- Add the mandatory `<merknad>` explaining the reverse charge method for codes
  81, 83, 86, 88, and 91.
- Clean the `company_kid` by safely stripping the 'NO' prefix, and 'MVA' suffix.

Expect:
The generated XML payload now adheres perfectly to Skatteetaten's strict
structural and mathematical rules, allowing the VAT return to pass government
validations successfully.

Related Community PR: https://github.com/odoo/odoo/pull/258390

Task-6033027

Forward-Port-Of: odoo/enterprise#116897
Forward-Port-Of: odoo/enterprise#110792

*: payment_sepa_direct_debit, sale_(stock_)renting, sale_(amazon,lazada,shopee),website_sale_(stock_)renting 

- Replace imports of `_` with calls to `self.env._()`.
- Since https://github.com/odoo/odoo/pull/174844, it is supported to translate
  Python strings through the environment using `self.env._()` instead of
  the bare `_()` function.
- Using bare `_` has become bad practice as it causes confusion with the
  Python convention of `_` as a throwaway variable, and fails in edge
  cases such as lambdas and generators where frame-based language
  detection does not work correctly.
- Therefore, within our scope, all occurrences of `_()` are replaced
  with `self.env._()` (or the relevant environment reference such as
  `request.env._()`) wherever possible.
- Module-level constants that require lazy evaluation are updated to use
  `LazyTranslate(__name__)` in place of the old `_lt` import.


SEE ALSO:
- Community PR:https://github.com/odoo/odoo/pull/262235

task-6139904

Currently an error occurs when user quick creates a picking type and tries to create a  receipt with it.

Steps to replicate:
- Install stock.
- Go to Inventory > Receipts and create a new receipt > Save it.
- Clear the Operation Type field, type `test` and quick create it.
- Save and the error will occur.

Error:
```
UndefinedFunction: operator does not exist: integer = boolean
LINE 1: SELECT number_next FROM ir_sequence WHERE id=false FOR UPDAT...
```

Cause:
- As the user quick created the picking type, the `sequence_code` field was not set and it is a required field [1], when we try to get `next_number` to create the name for the current stock picking this error occurs.

- In the versions before `saas-19.1` trying to quick create picking type will lead to a `Not-Null Violation` as `sequence_code` is a required field and then stock picking type form view will open up.

- This error occurs only after `saas-19.1` and above versions because this [PR] made the `sequence_code` field into a related field so its required constraint was removed and hence quick create creates a new picking type.

Solution:
- Disabled quick create for stock picking type.

[1]: https://github.com/odoo/odoo/blob/fe0550ad23ff9128099e7e4994938879a971dcc8/addons/stock/views/stock_picking_type_views.xml#L93

[PR]: https://github.com/odoo/odoo/pull/190305/changes#diff-79cbc763115661182c02285c07320098510f5686700359ddee67443b4893dc30L32-R32

sentry-7383206579

__

## Short functional explanation of the error
When setting a time off for an employee who has a flexible schedule, in the attendance app, on the calendar with the 'days' view. We can see that the hours are grayed out from 8 hours to 16 hours. However, according to this message:
https://www.odoo.com/mail/message/1027495005
"[...] the entire day of absence might not be represented as such, which is an issue (for example if a flexible employee with 8h/day takes a day off, the duration of the leave should be 1 day/8 hours but on the gantt view everything should be gray from midnight to midnight)".
Moreover, when we select the Week or Month view on the calendar, the day off isn't grayed out. This comes from the fact that, for a flexible schedule, we consider that any time of the day can be a working hour; and we only grey out days in the calendar where no hour has been worked at all. Hence, the hours considered during a flexible day off should be from midnight to 23:59:59.

## Reproduction Steps
1. Go to an employee's profile and set their schedule to flexible.
2. Create a time off of a one-day duration for this employee.
3. Go to the attendance app and see the calendar.

### Expected behavior
When clicking on the Day view, all hours from midnight to 11pm should be grayed out.

When clicking on the Week/month view, the day of the time off should be grayed out.

### Unexpected behavior
When clicking on the Day view, hours from 8am to 4pm are grayed out.

When clicking on the Week/month view, the day of the time off isn't grayed out.

## Origin of the issue
First, we only consider the leave if the resource is fully flexible, i.e if the employee has no working calendar set:
 https://github.com/odoo/odoo/blob/394a30f8a2814d460cfe220b5017e7ac95d8cddc/addons/resource/models/resource_calendar.py#L546
However, if the schedule of the employee is flexible, the leave resource isn't considered as fully flexible, thus leading us to a leave from 8 am to 4 pm.

Moreover, when processing flexible leaves, we return the unavailable intervals with the timezone of the employee:
https://github.com/odoo/odoo/blob/394a30f8a2814d460cfe220b5017e7ac95d8cddc/addons/resource/models/resource_calendar.py#L589-L592 Whereas when we process fixed leaves, we return the unavailable intervals under utc:
https://github.com/odoo/odoo/blob/394a30f8a2814d460cfe220b5017e7ac95d8cddc/addons/resource/models/resource_calendar.py#L597-L601

This leads us to display problems: when the user is under European/ Brussels time in summer, the leave starts at 2 am and ends at 11pm, instead of starting at midnight.
Note: after discussion with AJU, it has been agreed that the behavior
should be the same on the Planning app.
__
opw-6030212

**Steps to reproduce:**
- Create a new marketing campaign with two activities
- Set them to occur some number of days after the beginning
- Save the campaign and start it
- Modify one of the activities to occur some number of days after the
other activity and save
- Modify the child activity by changing the number of days after its
parent that it should run and save
- An error will be thrown

**Issue:**
The trace related to the child activity has no parent when trying to reschedule it in `_update_schedule_date`. This causes an issue when trying to get the first mailing_trace_ids using index 0 in this line:
`base_dt_str = trace.parent_id.schedule_date or trace.parent_id.mailing_trace_ids[0].write_date or trace.participant_id.create_date`

**Fix:**
Prevent the activity hierarchy to be modified on started campaigns.
We also change the indexing to avoid further out of range issue and
properly default on the participant create value.

Trying to match existing traces to their parents has too many edge cases when trying to avoid duplicates, and might often need to reset the whole trace chain to work properly. This approach avoids user mistakes on running
campaigns, but if a user tries to launch a test (even on draft campaign) he won't be able to modify the hierarchy further without deleting/recreating some activities/traces. So we should ignore this for test traces, but it could
impact the behavior between test and actual executions.

opw-5362978

Issue:
Unreconciling a payment in a batch payment from a recurring invoice will cause an invoice for the next recurring period to be generated

Steps to reproduce:
1. Create and confirm a monthly recurring invoice
2. Create a payment for the invoice
3. Create a batch payment and add the payment created in step 2 then validate it
4. Create a bank statement line and reconcile it with the batch payment created in step 3
5. Unreconcile the payment from the invoice from the invoice form view
6. Notice that a draft invoice for the next month’s recurring invoice is created

Cause:
When unreconciling the payment from the invoice via the invoice form view, the method “delete_reconciled_line” is called. In the “account_accountant_batch_payment” override of that method, it will reset the invoice back to draft and repost it. However, when posting a recurring invoice, the default behavior is to create the invoice for the next recurrence period

Solution:
Adding a new context flag called “skip_recurring_copy” will prevent the next period’s recurring invoice from being generated when invoices are posted through “delete_reconciled_line”

Community PR: https://github.com/odoo/odoo/pull/263991

opw-6158881

Issue
--------------
When refreshing checks on account returns (e.g. from rapid successive clicks or component re-renders), multiple concurrent RPC calls to `refresh_checks` were being dispatched to the server. This created a race condition that resulted in duplicate `account.return.check` records being generated in the database.

steps to reproduce demonstrated in video: https://drive.google.com/file/d/1-A0ZHdYGdv-UL0dqClqK6Kos_iVXoZai/view?usp=sharing

When this happen the `runAllReturnChecks` method fires parallel RPC calls to [`refresh_checks`](https://github.com/odoo/enterprise/blob/55bfd499660d3eda0abfc9e8ed8c9a2befbd394b/account_reports/models/account_return.py#L1974-L1992) on the server. In the case of instant multiple RPC calls, parallel threads are dispatched which causes the data preparation stage to run simultaneously.


Because both threads run in parallel, Thread 2 runs its [preparation and existing ](https://github.com/odoo/enterprise/blob/55bfd499660d3eda0abfc9e8ed8c9a2befbd394b/account_reports/models/account_return.py#L1986-L1987 )check mechanism before Thread 1 has reached the actual `create()` function [trigger](https://github.com/odoo/enterprise/blob/55bfd499660d3eda0abfc9e8ed8c9a2befbd394b/account_reports/models/account_return.py#L1998-L1999).  Consequently, Thread 2's existence check fails to find the record (since Thread 1 hasn't committed it to the database yet), and it considers the record eligible for creation—even though the exact same record is already prepared for creation by Thread 1. This race condition leads to duplicate `account.return.check` records.

   
   
 Logs to demonstrate the thread execution:
--------

```python
2026-04-16 08:30:51,493 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:51] "GET /websocket?version=19.0-2 HTTP/1.0" 400 - 1 0.000 0.002
2026-04-16 08:30:51,662 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:51] "POST /web/dataset/call_kw/account.report/dispatch_report_action#account.report.dispatch_report_action HTTP/1.0" 200 - 17 0.006 0.012
2026-04-16 08:30:51,847 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:51] "POST /web/dataset/call_kw/account.return/get_views#account.return.get_views HTTP/1.0" 200 - 26 0.009 0.025
2026-04-16 08:30:52,099 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:52] "POST /web/dataset/call_kw/account.return/web_read_group#account.return.web_read_group HTTP/1.0" 200 - 95 0.029 0.064
2026-04-16 08:30:52,320 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:52] "POST /web/dataset/call_kw/account.return/get_next_returns_ids#account.return.get_next_returns_ids HTTP/1.0" 200 - 2 0.001 0.004
                 THREAD NAME: odoo.service.http.request.137360481711808 Thread ID:  137360481711808
                 REFRESH CHECK START:--------------------------------------------
                 Thread ID:   137360481711808 -------------DATA PREPARING STAGE------------
                 Thread ID:   137360481711808
                 Thread ID:   137360481711808     RECORD EXISTING CHECK:  None
2026-04-16 08:30:53,842 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:53] "GET /odoo/tax-report/tax-return?debug=1 HTTP/1.0" 200 - 29 0.020 0.021
2026-04-16 08:30:54,066 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "GET /web/webclient/load_menus HTTP/1.0" 200 - 4 0.002 0.009
2026-04-16 08:30:54,351 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "GET /web/manifest.webmanifest HTTP/1.0" 200 - 6 0.003 0.005
2026-04-16 08:30:54,493 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "GET /web/webclient/translations?hash=bb5aa713d587cc7dd07b13d1d7efc2c525517e99&lang=en_US HTTP/1.0" 200 - 1 0.000 0.002
2026-04-16 08:30:54,586 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "GET /web/bundle/web_tour.interactive?lang=en_US&debug=1 HTTP/1.0" 200 - 1 0.001 0.003
2026-04-16 08:30:54,640 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "POST /web/action/load_breadcrumbs HTTP/1.0" 200 - 7 0.003 0.006
2026-04-16 08:30:54,710 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "POST /web/dataset/call_kw/ir.http/lazy_session_info#ir.http.lazy_session_info HTTP/1.0" 200 - 2 0.001 0.004
2026-04-16 08:30:54,753 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "GET /bus/websocket_worker_bundle?v=19.0-2 HTTP/1.0" 304 - 3 0.004 0.006
2026-04-16 08:30:54,766 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "GET /web/image?model=res.users&field=avatar_128&id=2 HTTP/1.0" 304 - 9 0.012 0.013
2026-04-16 08:30:54,777 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "POST /mail/data HTTP/1.0" 200 - 34 0.034 0.020
2026-04-16 08:30:54,824 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "POST /web/dataset/call_kw/account.return/get_views#account.return.get_views HTTP/1.0" 200 - 3 0.001 0.010
2026-04-16 08:30:54,934 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "POST /web/dataset/call_kw/account.return/web_read_group#account.return.web_read_group HTTP/1.0" 200 - 88 0.029 0.051
2026-04-16 08:30:55,107 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:55] "POST /web/dataset/call_kw/account.return/get_next_returns_ids#account.return.get_next_returns_ids HTTP/1.0" 200 - 2 0.001 0.005
                 THREAD NAME: odoo.service.http.request.137360513177280 Thread ID:  137360513177280
                 REFRESH CHECK START:--------------------------------------------
                 Thread ID:   137360513177280 -------------DATA PREPARING STAGE------------
                 Thread ID:   137360513177280
                 Thread ID:   137360513177280     RECORD EXISTING CHECK:  None
2026-04-16 08:30:55,589 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:55] "GET /websocket?version=19.0-2 HTTP/1.0" 400 - 1 0.001 0.006
2026-04-16 08:30:56,702 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:56] "GET /web/service-worker.js HTTP/1.0" 200 - 1 0.000 0.003
2026-04-16 08:30:58,893 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:58] "GET /websocket?version=19.0-2 HTTP/1.0" 400 - 1 0.006 0.023
2026-04-16 08:31:05,296 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:31:05] "GET /websocket?version=19.0-2 HTTP/1.0" 400 - 1 0.001 0.002
                 Thread ID:   137360481711808     DATA to_create:  168
                 Thread ID:   137360481711808 done process create  
2026-04-16 08:31:10,132 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:31:10] "POST /web/dataset/call_kw/account.return/refresh_checks#account.return.refresh_checks HTTP/1.0" 200 - 513 11.611 6.039
                 Thread ID:   137360513177280     DATA to_create:  168
                 Thread ID:   137360513177280 done process create 

```

- OPW: 5917459

__

## Short functional explanation of the error
When printing delivery slips, the description of kit components isn't shown. Therefore, we only see the components on the slip, and not the kit they come from.

## Reproduction Steps
1. Go to settings. Under Inventory, in the Operations section, enable Packages.
2. Go to Sales and create a new quotation. Select a customer and add a kit product. Click on confirm.
3. Click on the Delivery smart button. Click on Put in Pack and Validate.
4. Click on the small cog > Print > Delivery Slip.

### Expected behavior
The kit from which the components belong should be indicated somewhere on the slip.

### Unexpected behavior
The kit isn't indicated.

## Origin of the issue
When we print a delivery slip without putting in pack, we can see on the slip that the first line, in bold, corresponds to the kit name. However, after putting in pack, the first line, in bold, indicates the Package id:
https://github.com/odoo/odoo/blob/80b602f2fa82366280f9beaa3414c27293bdc4f6/addons/stock/report/report_deliveryslip.xml#L116 Thus, the lines after will correspond to the components, of which we retrieve the details with:
https://github.com/odoo/odoo/blob/80b602f2fa82366280f9beaa3414c27293bdc4f6/addons/stock/report/report_deliveryslip.xml#L125 However, in `_get_aggregated_product_quantities`, we set the description of the components to an empty string under that case: https://github.com/odoo/odoo/blob/80b602f2fa82366280f9beaa3414c27293bdc4f6/addons/mrp/models/stock_move.py#L180-L181 leaving us with no description for the components, and therefore not indicating the kit to which they belong.

__
opw-6006514

- Attendance checkout
    - Step to reproduce: with attendance installed and an employee checked in, archive that employee by HR user. If missing attendance rights, the employee will be archived but not checked out from its ongoing attendance.
    - Cause: if no role set for Attendance (default), no permission to update the employee attendance while archiving.
    - Solution: using sudo method so that any user with sufficient rights to archive an employee, can trigger check out of the corresponding attendance.

- Planning access error (fixed in 18.0 by https://github.com/odoo/odoo/pull/219395)
    - Step to reproduce: with attendance and planning installed, archive an employee having planning slots. If missing planning rights, an access error is raised
    - Cause: on employee archive, the corresponding planning.slots are updated and some fields recomputed with insufficient rights.
    - Solution: using sudo method for recompute.

Task: 6131692

Forward-Port-Of: odoo/odoo#260566

When applying a cash rounding with 'biggest tax' strategy, it happens
that we end up with a MissingError when the invoice's partner is not
defined as commercial_partner_id.

Steps:

- Install membership module
- Create a cash rounding with the 'biggest tax' strategy and 0.05
  rounding
- Enable customer addresses and create a partner P with an invoice
  address I
- Create an invoice, select I as customer (P will be assigned as
  delivery address but this is not relevant)
- Add an invoice line for 100.03 and any tax and apply the cash rounding
- Confirm
-> MissingError: record has been deleted

Cause:

- When creating the cash rounding lines, we set the `partner_id` from the
invoice's partner (in our case partner I, which has P as
`commercial_partner_id`).
- When posting the invoice we look for lines that have partner id
  different than the invoice's commercial partner id and we call the
  write method to set the commercial partner id instead
  https://github.com/odoo/odoo/blob/832165841f66675c0238652c5b0e5e0b6f75ca43/addons/account/models/account_move.py#L5234-L5239
- In some cases, for example in the `membership` module, the override of
  the write method calls the super() before using `self`.
  https://github.com/odoo/odoo/blob/832165841f66675c0238652c5b0e5e0b6f75ca43/addons/membership/models/account_move.py#L45-L49
  But the super triggers the `_sync_tax_lines` mechanism, during which
  the rounding line in deleted
  https://github.com/odoo/odoo/blob/832165841f66675c0238652c5b0e5e0b6f75ca43/addons/account/models/account_tax.py#L3102-L3110
  https://github.com/odoo/odoo/blob/832165841f66675c0238652c5b0e5e0b6f75ca43/addons/account/models/account_move.py#L3113-L3114
  Therefore `self` doesn't exist anymore
  when comming back in the override

Fix:

Setting the commercial partner on the rounding line to avoid calling the write method

opw-6128868