# Setup
You'll need a User with :
- An active contract (for easiness of testing, a contract that started long ago with 8hrs/day)

# How to reproduce
- Create a new Time Off type with "Ignore Public Holidays" enabled
- Create a Public Holiday for Period X
- Create A Time Off request for the User for a Period Y that contains Period X
- Go to the Time Off Ledger
- Remove the Missing Hours filter and search for the dates in Period Y

Exemple of periods :
- Period X => Feb 10 2026 - Feb 10 2026
- Period Y => Feb 9 2026 - Feb 11 2026

# The problem
The "Approved Time Off" and "Difference" values are wrong.

With the given exemples, we'll see Feb 9 and Feb 11 with "Approved Time Off" values of 12hrs, which is wrong since the employee is supposed to work 8hrs a day, so he should have a time off of also 8hrs.

# Cause
The calculation for "Approved Time Off" is the following :
Divide the `number_of_hours` of a hr_leave
By the number of working days during the period of the leave

Using our exemple, we get :
`number_of_hours` = 24hrs
number of working days = 2
Approved Time Off = 24hrs / 2 => 12hrs, but we expect 8hrs

The `number_of_hours` is correct since we checked "Ignore Public Holidays" (which actually means : include the public holidays in the number of hours of a leave)

The problem is that the aggregation for the number of working days excludes automatically
public holidays, without paying attention to the value of "Ignore Public Holidays" :
https://github.com/odoo/odoo/blob/5e623af55fba64e812db6bcaf06d8f7c5d08f055/addons/hr_holidays_attendance/report/hr_leave_attendance_report.py#L193-L202
Explanation for this part of the query : we only keep days where there is no record in
resource_calendar_leaves (`WHERE rcl2.id IS NULL`)  that contains that day
and that are considered public (`AND rcl2.resource_id IS NULL`)

# Proposed Solution
We add a `JOIN hr_leave_type` to be able to get the value for
`include_public_holidays_in_duration` ("Ignore Public Holidays").

Then, we make it so we exclude the Public Holidays only if that value is
false (`AND NOT lvt.include_public_holidays_in_duration`)

opw-6082422

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

Forward-Port-Of: odoo/odoo#261259
Forward-Port-Of: odoo/odoo#258963

Problem:
When the contact type is set for a related (child) contact, the contact type is shown in English next to the contact name in the contact list view. It should be translated to the user language. It is correctly translated in the Kanban view.

Steps to reproduce:
1. Install the Contacts app.
2. Create a contact or go to an existing contact
3. Add a related (child) contact and set its contact type to any type (i.e. Invoice Address)
4. Change the user language to any language other than English
5. Go back to the contact list view and check the name of the related (child) contact. See how the contact type appearing in the name is in English instead of being translated, while it is correctly translated in the Kanban view.

Cause:
The list view uses the 'complete_name' field which is not translated, while the Kanban view uses the 'display_name' field which is translated.

Solution:
Use the 'display_name' field instead of 'complete_name' in the list view.

opw-5947987

Forward-Port-Of: odoo/odoo#261592
Forward-Port-Of: odoo/odoo#257539

Problem:
When the contact type is set for a related (child) contact, the contact type is shown in English next to the contact name in the contact list view. It should be translated to the user language. It is correctly translated in the Kanban view.

Steps to reproduce:
1. Install the Contacts app.
2. Create a contact or go to an existing contact
3. Add a related (child) contact and set its contact type to any type (i.e. Invoice Address)
4. Change the user language to any language other than English
5. Go back to the contact list view and check the name of the related (child) contact. See how the contact type appearing in the name is in English instead of being translated, while it is correctly translated in the Kanban view.

Cause:
The list view uses the 'complete_name' field which is not translated, while the Kanban view uses the 'display_name' field which is translated.

Solution:
Use the 'display_name' field instead of 'complete_name' in the list view.

opw-5947987

Forward-Port-Of: odoo/enterprise#115331
Forward-Port-Of: odoo/enterprise#114786

Issue:
---
Canonical address is not correctly calculated in non-default lang.

Steps to reproduce:
1- Create a website with 2 lang: en, fr
2- Create a product with a website category.
3- Navigate to the shop in fr.
4- Open the category, then open the product.
5- Open console, and search for canonical.

As you see, in the second language, the canonical address includes the category address which is wrong.
If you visit in the default lang, the canonical correctly refers to the url without category.

Cause:
---
This is because `_get_canonical_url` override relies on `self.env['ir.http']._match`, which will not work with an url prefixed by language code, raising `NotFound`. This leads to rule to be set as `None`. As a result canonical address will be set as the canonical address from `website` module's implementation, which doesn't take website category case into account. This lead to canonical address of `/lang-code/shop/category/product` to be itself.

opw-6086206

Forward-Port-Of: odoo/odoo#258834

Steps to produce:
---
- Install `mrp`.
- Go to Manufacturing > Products > Bills of Materials.
- Click Create, select a product.
- In the Product Variant field, type any value and click "Create".

Issue:
---
Using quick create on the Product Variant field does
not create a variant of the selected product template. Instead, it
creates a completely new, unrelated `product.template`. This is because
the `create()` method on `product.product` is overridden to call super()
with context `create_product_product=False`, which suppresses direct
variant creation and forces creation through `product.template` instead,
see [1].

**Why passing `default_product_tmpl_id` does not help:**
One might expect that passing `default_product_tmpl_id` in the field
context would cause the newly quick-created `product.product` to be
linked to the already-selected `product.template`. However, because of
the `create()` override above (introduced in [commit]), the variant
creation is always redirected to `product.template`, ignoring any
`default_product_tmpl_id` passed in context. It is therefore not possible
in any case to quick-create a `product.product` that is correctly and
directly linked to the currently selected `product.template`.

Fix:
---
Disable the "Create" and "Create and Edit" options. Since there is no
way to quick-create a `product.product` that is correctly linked to the
currently selected `product.template`, the user must create the variant
directly on the product template first.

[1]https://github.com/odoo/odoo/blob/f04d79d44873d0f1c35303a1a892f3a3a394ea17/addons/product/models/product_product.py#L364-L368

[commit]: https://github.com/odoo/odoo/commit/7389345696720255a9d3c72ca1d9c2f4e4ecd7b8

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

Forward-Port-Of: odoo/odoo#261316
Forward-Port-Of: odoo/odoo#259776

### Issue
Two bugs reported in the Barcode app / Manufacturing Order flow:

**1. UoM change after confirm leaves MO inconsistent** Changing the UoM on a confirmed MO via the Barcode app does not recalculate `product_qty` / `qty_producing`. The backend locks the UoM after confirm — the Barcode view did not.

**2. `qty_producing` reset on wizard open/close**
Typing a value in `qty_producing` then opening the "Change Qty to Produce" widget (even closing without saving) caused the typed value to vanish. Root cause: the widget's `onClose` calls `env.model.load()`, which refetches from DB and discards any unsaved form edits.

### Fix
- `product_uom_id` in the Barcode MO form is now readonly once `state != 'draft'`, matching the backend.
- `openChangeQtyWizard` now saves the record before opening the wizard, so pending edits survive the reload.

### Steps to reproduce
**UoM bug**
1. Create an MO, confirm it.
2. Open it in the Barcode app.
3. Try to change the UoM → it was editable (bug).

**Qty reset bug**
1. Open a confirmed MO in the Barcode app, go to the header product page.
2. Type a value in `qty_producing` (e.g. `3`).
3. Click the `/ X` button next to it (opens the Change Qty wizard) then close it without clicking "Set Quantity".
4. `qty_producing` reverts to its previous value (bug).

### After the fix
- UoM field is greyed out once the MO is confirmed.
- Typed value in `qty_producing` is preserved after opening and closing the wizard.

opw-5809178

Forward-Port-Of: odoo/enterprise#114452
Forward-Port-Of: odoo/enterprise#114075

### Issue before this commit:
When sending a payment reminder email for a subscription using the email composer, the template  was not correctly populated with the expected dynamic values. In particular, fields such as the subscription closing date and the subscription code were missing.

### Steps to reproduce the issue:
1. Install subscription and go to that app
2. Open one subscription
3. Send message > Load template: "Subscription: Payment Reminder"
4. Sentence is incomplete: missing end date of the subscription

### Cause of the issue:
The issue was caused by the absence of a proper context injection when rendering the email template from the mail.compose.message wizard. The template relied on context variables like date_close, but these values were not being computed nor passed during manual email composition. Unlike automated flows, the composer did not provide the subscription-specific context required by the template.

### Reason to introduce the fix:
The fix makes the payment reminder and closing templates self-sufficient by replacing context-based values with fields and helper methods directly available on the subscription record. A dedicated method is introduced to compute the subscription close date consistently, so the templates render the expected values both in automated flows and when manually loaded from the email composer.

opw-6031613

Forward-Port-Of: odoo/enterprise#114839
Forward-Port-Of: odoo/enterprise#111801

**Steps to reproduce:**
* Install the *Inventory* (`stock`) module.
* Create a *Storable Product* and set some *On Hand* quantity.
* Go to *Inventory → Operations → Receipts*.
* Create a new receipt.
* Add the product with a *Demand* quantity (e.g. 10).
* Validate the receipt:
  * Case 1: Validate with less quantity than demand (e.g. 8) and choose *No Backorder*.
  * Case 2: Validate with more quantity than demand (e.g. 12).
* Click on *Print( Delivery Slip)*.

**Observed behavior:**
* The *Ordered Quantity* is equal to the *Delivered Quantity*.
  * Case 1 (Demand=10, Done=8):
    * Ordered = 8, Delivered = 8.
  * Case 2 (Demand=10, Done=12):
    * Ordered = 12, Delivered = 12.

**Expected behavior:**
* Case 1 (Demand=10, Done=8):
    * Ordered = 10, Delivered = 8.
  * Case 2 (Demand=10, Done=12):
    * Ordered = 10, Delivered = 12.

 **Cause:**
* Clicking on *Print* triggers `stock.action_report_delivery`: https://github.com/odoo/odoo/blob/5c1000cb11da64bf317f9bd9b0ae71f6fbea910d/addons/stock/views/stock_picking_views.xml#L156
* This renders `stock.report_deliveryslip`: https://github.com/odoo/odoo/blob/5c1000cb11da64bf317f9bd9b0ae71f6fbea910d/addons/stock/report/stock_report_views.xml#L14
* The QWeb template calls `report_delivery_document`: https://github.com/odoo/odoo/blob/5c1000cb11da64bf317f9bd9b0ae71f6fbea910d/addons/stock/report/report_deliveryslip.xml#L288-L292
* Which relies on `_get_aggregated_product_quantities`: https://github.com/odoo/odoo/blob/5c1000cb11da64bf317f9bd9b0ae71f6fbea910d/addons/stock/report/report_deliveryslip.xml#L157

CASE- 1
* When validating with *less quantity* and *no backorder*:
  * In `_get_aggregated_product_quantities`, `qty_ordered` is initialized to `None` and only set when `backorders and not kwargs.get('strict')`: https://github.com/odoo/odoo/blob/5c1000cb11da64bf317f9bd9b0ae71f6fbea910d/addons/stock/models/stock_move_line.py#L881
  * If no backorder exists, the condition fails and `qty_ordered` remains `None` and it come out of condition
  * where it take  quantity `'qty_ordered': qty_ordered or quantity,` https://github.com/odoo/odoo/blob/5c1000cb11da64bf317f9bd9b0ae71f6fbea910d/addons/stock/models/stock_move_line.py#L898
  * As a result, *Ordered Quantity* becomes equal to *Delivered Quantity*.

CASE-2
* When validating with *more quantity* than demanded:
  * `_action_done` creates an extra move using `_create_extra_move()`: https://github.com/odoo/odoo/blob/5c1000cb11da64bf317f9bd9b0ae71f6fbea910d/addons/stock/models/stock_move.py#L1936
  * The extra move is merged back via `_action_confirm(merge_into=self)`: https://github.com/odoo/odoo/blob/5c1000cb11da64bf317f9bd9b0ae71f6fbea910d/addons/stock/models/stock_move.py#L1878
  * The original move keeps `product_uom_qty = 10` but now has two move lines (10 + 2).
  * In `_get_aggregated_product_quantities`: Both move lines share the same `line_key`
- **ML1** → `line_key` not yet in dict → enters [if] https://github.com/odoo/odoo/blob/5c1000cb11da64bf317f9bd9b0ae71f6fbea910d/addons/stock/models/stock_move_line.py#L880 **ML2** → `line_key` already in dict → enters `else` block https://github.com/odoo/odoo/blob/5c1000cb11da64bf317f9bd9b0ae71f6fbea910d/addons/stock/models/stock_move_line.py#L901-L903
  → `qty_ordered += 2`  →  `qty_ordered = 12`  ✗  (surplus added to demand)
  → `quantity += 2`     →  `quantity = 12`      ✓
  * The `else` branch was designed to aggregate multiple lines of the
same product (e.g. two lot lines). The bug was that it added the
**done qty** of each line to `qty_ordered` unconditionally, causing
the surplus from over-delivery to inflate the ordered quantity.

* After the fix:
  * Case 1 (Demand=10, Done=8):
    * Ordered = 10, Delivered = 8.
  * Case 2 (Demand=10, Done=12):
    * Ordered = 10, Delivered = 12.
    
*  NOTE:
Adapt the existing test case `test_kit_packaging_delivery_slip`
 to reflect the corrected behavior of delivery validation.
The test was originally introduced in this [commit](https://github.com/odoo/odoo/pull/161920/changes/47da1ec13a2189e826d3b0539e6494e35990ccc1).
Its main objective is to ensure that the Delivery Slip report prints successfully

Previously, when validating a transfer with:
Delivered quantity less than the demanded quantity, No backorder created
the Ordered Quantity was being reduced(24->12) to the delivered quantity.
After the fix, the Ordered Quantity correctly remains equal(24->24) to the original demand.

<details>
  <summary>Click here to see the results:</summary>

  <p><strong>Before:</strong></p>
  <div>
    <img src="https://github.com/user-attachments/assets/88d24079-b278-4ef9-bff2-c7f14fe7ecb7" />
    <img src="https://github.com/user-attachments/assets/c6181771-7d91-4ffe-9ed8-17dffac346f7" />
  </div>

  <p><strong>After:</strong></p>
  <div>
    <img src="https://github.com/user-attachments/assets/6ed57881-8af3-42ad-94d4-7c44a5b9b00e" />
    <img src="https://github.com/user-attachments/assets/b5506c81-3ed9-416b-8099-108a75588b13" />
  </div>
</details>

---

opw-5874759

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

Forward-Port-Of: odoo/odoo#261612
Forward-Port-Of: odoo/odoo#250587

How to reproduce:
- Select an employee with an overtime ruleset and work entries based on
attendances
- Create attendance with an approved overtime
- Go to "Work Entries" in Payroll, and regenerate the work entries for the
following day of the attendance
- A new overtime work entry is generated on the first day.

Reason:
Because of how regenerating work entries is done, the computed date for
searching overtime lines took into account the previous day (i.e. regenerating
a work entry for a tuesday in an UTC+1 timezone made it so the starting date
was on monday at 23:00:00), and since the _read_group only looked at the
date part of the time start without taking into account the hour, it
included the overtime of the previous day.

How it was fixed:
The domain now takes into account the timezone of the employee to generate the
domain for the _read_group to ensure the correct day is selected

Task ID: 5899657

Forward-Port-Of: odoo/enterprise#115032
Forward-Port-Of: odoo/enterprise#107266

### Issue
Two bugs reported in the Barcode app / Manufacturing Order flow:

**1. UoM change after confirm leaves MO inconsistent** Changing the UoM on a confirmed MO via the Barcode app does not recalculate `product_qty` / `qty_producing`. The backend locks the UoM after confirm — the Barcode view did not.

**2. `qty_producing` reset on wizard open/close**
Typing a value in `qty_producing` then opening the "Change Qty to Produce" widget (even closing without saving) caused the typed value to vanish. Root cause: the widget's `onClose` calls `env.model.load()`, which refetches from DB and discards any unsaved form edits.

### Fix
- `product_uom_id` in the Barcode MO form is now readonly once `state != 'draft'`, matching the backend.
- `openChangeQtyWizard` now saves the record before opening the wizard, so pending edits survive the reload.

### Steps to reproduce
**UoM bug**
1. Create an MO, confirm it.
2. Open it in the Barcode app.
3. Try to change the UoM → it was editable (bug).

**Qty reset bug**
1. Open a confirmed MO in the Barcode app, go to the header product page.
2. Type a value in `qty_producing` (e.g. `3`).
3. Click the `/ X` button next to it (opens the Change Qty wizard) then close it without clicking "Set Quantity".
4. `qty_producing` reverts to its previous value (bug).

### After the fix
- UoM field is greyed out once the MO is confirmed.
- Typed value in `qty_producing` is preserved after opening and closing the wizard.

opw-5809178

Forward-Port-Of: odoo/enterprise#114452
Forward-Port-Of: odoo/enterprise#114075

This commit refactors the import code of BIS3 Invoice to fix various issues about unsynchronized values between the imported invoice and the source XML file.

The new way we import BIS3 invoice can be categorized as:

- collecting all the values from the XML to a dictionary object
- prepare the values and amounts to write to the invoice in its entirety using the tax computation engine helpers
- write the whole processed values to the invoice (as a single write)
- (in 18.0 ~ 18.2) recalculate discrepancies and update the invoice lines (if needed) with the corrected amounts

This commit also includes a new test suite for BIS3 import, and a new approach of import testing, "Partial Imports", is introduced to better atomize the big import test files (and make it understandable). In the long term, `l10n_account_edi_ubl_cii_tests` will eventually be removed in favor of these small-but-many partial tests.

task-id: 5058687

Co-authored-by: Yosua Nicolaus <yoni@odoo.com>

Forward-Port-Of: odoo/odoo#260803
Forward-Port-Of: odoo/odoo#250160

### Issue
Two bugs reported in the Barcode app / Manufacturing Order flow:

**1. UoM change after confirm leaves MO inconsistent** Changing the UoM on a confirmed MO via the Barcode app does not recalculate `product_qty` / `qty_producing`. The backend locks the UoM after confirm — the Barcode view did not.

**2. `qty_producing` reset on wizard open/close**
Typing a value in `qty_producing` then opening the "Change Qty to Produce" widget (even closing without saving) caused the typed value to vanish. Root cause: the widget's `onClose` calls `env.model.load()`, which refetches from DB and discards any unsaved form edits.

### Fix
- `product_uom_id` in the Barcode MO form is now readonly once `state != 'draft'`, matching the backend.
- `openChangeQtyWizard` now saves the record before opening the wizard, so pending edits survive the reload.

### Steps to reproduce
**UoM bug**
1. Create an MO, confirm it.
2. Open it in the Barcode app.
3. Try to change the UoM → it was editable (bug).

**Qty reset bug**
1. Open a confirmed MO in the Barcode app, go to the header product page.
2. Type a value in `qty_producing` (e.g. `3`).
3. Click the `/ X` button next to it (opens the Change Qty wizard) then close it without clicking "Set Quantity".
4. `qty_producing` reverts to its previous value (bug).

### After the fix
- UoM field is greyed out once the MO is confirmed.
- Typed value in `qty_producing` is preserved after opening and closing the wizard.

opw-5809178

Forward-Port-Of: odoo/enterprise#114452
Forward-Port-Of: odoo/enterprise#114075

[FIX] project_timesheet_holidays: Exclude archived employees from time-off 

# Description of the issue/feature this PR addresses:
## Steps to Reproduce:
1. Create a time off for Employee A (it should affect the timesheets).
2. Create a new public holiday (global time off) that overlaps with Employee A’s time off.
3. Archive Employee A.
4. Delete the public holiday created in step 2.
5. An error related to timesheet generation appears.

## Expected Behavior:
- The public holiday / global time off should be deleted without any error.

# Desired behavior after PR is merged:
## Fix (Implemented):
When regenerating timesheets due to changes in holidays or time off, leaves related to archived employees should not be taken into account. A check was added inside the `_generate_timesheets` function in `project_timesheet_holidays/models/hr_holidays.py` to exclude leaves belonging to archived employees.

## Alternative Fix (Not Implemented):
Instead of filtering out leaves linked to archived employees, we could delete those leaves when an employee is archived. However, this approach is not ideal, as archived employees may be reactivated later and would still need their previously requested time off to be preserved.

 ## Version:
 This bug appears in both version 17.0 and 19.0. I assumed that it also appears in 18.0  but didn't directly test

## Task:

[5474038](https://www.odoo.com/odoo/project/4105/tasks/5474038)

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

Forward-Port-Of: odoo/odoo#260725
Forward-Port-Of: odoo/odoo#244203

### Steps to reproduce:

- In the settings: Enable "Storage Locations"
- Inventory > Configuration > Warehouse Management > Operation Types
- On receipts, in the Barcode App tab enable: "Force a destination on all products"
- Open the barcode app, create a new receipt
- Scan a product > Validate
#### > You are not blocked by the fact that you did not scan any destination even just to validate the default one

### Cause of the issue:

The `barcode_validation_after_dest_location` operation type setting is not used at any point in the barcode app.

### Note:

Line in the barcode app are always created a with a `location_dest_id`: https://github.com/odoo/enterprise/blob/a220fc61d9076decdb987421df9330a1c2c20546/stock_barcode/static/src/models/barcode_picking_model.js#L1310-L1322
In particular, even if the setting says: Force a destination on all products. It should rather be interpreted as force a destination scan before validation. Note that a destination scan will not necessarily update a single line but rather all concerned lines at once: https://github.com/odoo/enterprise/blob/a220fc61d9076decdb987421df9330a1c2c20546/stock_barcode/static/src/models/barcode_picking_model.js#L1558-L1576
It is therefore a valid call to check if a location dest was scanned to determine if the a destination was set on each product before validation of the picking, even if it is just to confirm the default destination.

### Note 2:

We modify the `_get_barcode_config` to only provide a `barcode_validation_after_dest_location` if locations re enabled otherwise users enabling the option without the ability to scan locations would be soft lock and unable to validate their picking. That same logic already being applied to the `restrict_scan_dest_location` config parameter:
https://github.com/odoo/enterprise/blob/6afe02e3e836df2822d7cae8aebbd5bdde6b34cc/stock_barcode/models/stock_picking_type.py#L109

opw-6110690

Forward-Port-Of: odoo/enterprise#114429

### Issue
Two bugs reported in the Barcode app / Manufacturing Order flow:

**1. UoM change after confirm leaves MO inconsistent** Changing the UoM on a confirmed MO via the Barcode app does not recalculate `product_qty` / `qty_producing`. The backend locks the UoM after confirm — the Barcode view did not.

**2. `qty_producing` reset on wizard open/close**
Typing a value in `qty_producing` then opening the "Change Qty to Produce" widget (even closing without saving) caused the typed value to vanish. Root cause: the widget's `onClose` calls `env.model.load()`, which refetches from DB and discards any unsaved form edits.

### Fix
- `product_uom_id` in the Barcode MO form is now readonly once `state != 'draft'`, matching the backend.
- `openChangeQtyWizard` now saves the record before opening the wizard, so pending edits survive the reload.

### Steps to reproduce
**UoM bug**
1. Create an MO, confirm it.
2. Open it in the Barcode app.
3. Try to change the UoM → it was editable (bug).

**Qty reset bug**
1. Open a confirmed MO in the Barcode app, go to the header product page.
2. Type a value in `qty_producing` (e.g. `3`).
3. Click the `/ X` button next to it (opens the Change Qty wizard) then close it without clicking "Set Quantity".
4. `qty_producing` reverts to its previous value (bug).

### After the fix
- UoM field is greyed out once the MO is confirmed.
- Typed value in `qty_producing` is preserved after opening and closing the wizard.

opw-5809178

Forward-Port-Of: odoo/enterprise#114452
Forward-Port-Of: odoo/enterprise#114075

## Issue
When creating a time off for a date that is already covered by a confirmed payslip, that time off
cannot be deleted.

## Steps to reproduce
1. Install *Time Off in Payslips* (`hr_payroll_holidays`)
2. Create or use an employee E with a running contract, e.g.:
    - Contract: Jan 1 to Indefinite
    - Wage: $1000/month
3. In Payroll > Payslips, create a new Off-Cycle for Employee E:
    - Period: March 1 - March 31
    - *Compute Sheet*, *Confirm* and *Mark as paid*
4. In Time Off > Management > Time Off, create a new time off allocation for Employee E:
    - Date: anywhere during March
    - *Save* and *Validate*
5. Try to delete the allocation
6. **An error occurs: _"The pay of the month is already validated with this day included. If you need to adapt, please refer to HR."_**

## Cause
The condition under which this error is raised is defined in `_check_uncovered_by_validated_payslip`:

https://github.com/odoo/enterprise/blob/0226ad15abc8db70f8e379fddec3d83d15749c85/hr_payroll_holidays/models/hr_leave.py#L195-L203

It was originally added by https://github.com/odoo/enterprise/commit/1abb4a815ecb32557fc773cae54baf3e205d9b8c to prevent the deletion of holidays created **before** validating a payslip.

The condition does not take in account the moment when the leave was created. If a leave is created after the computation of the payslip, it did not impact that payslip, and thus can be deleted without risk.

opw-6089990

Steps to reproduce-
1) In a multi-company environment, create an employee in a secondary company. 
2) Link a Portal User to this employee via the user_id field. 
3) Create and validate a payslip for this employee. 
4) Run the 'Payroll: Generate pdfs' cron.

Error - ValidationError: The following user(s) cannot own root documents/folders:
portal_employee: Payslip - portal_employee

Cause - The validation logic uses the employee_id field on res.users to check if a user is an employee. Since employee_id is a non-stored computed field, its value depends on the current company context (self.env.company).

When the payroll cron runs under the OdooBot user in the default company context (ID = 1), it cannot resolve the employee_id for users belonging to other companies. The field evaluates to False, causing the system to incorrectly flag the user as an unauthorized document owner.

Fix - Replace the validation check with the employee boolean field. Unlike the computed Many2one, employee is a stored field that is not restricted by the active company context. This ensures that a user's employee status is correctly identified during background tasks across all companies.

opw-6143042

Co-authored by Tina Lin (liti)

When creating a refund of a pos order linked to a SO the delivery is not created.

Steps to reproduce:
-------------------
* Create a product tracked by quantity
* Create a SO with the product and confirm it
* Open a session and settle the SO
* Go backend
* Refund the order & pay it
* See the delivery created
> Obsrevation: it has no move lines.
The pos order that settled the SO has move lines.

Why the fix:
------------
Version 18.0 is the only version that filters the lines when creating moves.
We notice the following commit: https://github.com/odoo/odoo/commit/e6678442ffe90e35a00e8b752e607d839920bee6

In the next version we're back with the original line as the logic was moved to a newly created module:
https://github.com/odoo/odoo/commit/42bcc2b49d46695c4afc518bb0f89254e24c12dc

Having a consistent code across version would solve this issue without triggering any issue on the test but the test was passing without the original fix.

So instead we'll add a specific fix here as well to keep the original logic.

A different behavior can be observed if we're refunding from the front or backend. When refunding from the front the refund order is not linked to the original SO thus `lines` don't get filtered. The difference with the backend comes from the fact that the refund is linked to the SO and thus the lines are filtered and we end up using no pos lines for creating move lines.

As this behavior is consistent across versions we don't want to modify it for only 1 version. Plus if we modify the front behavior we still have the issue anyway.

So not if the order has an origin SO id but is a refund of that original SO we don't filter it out for moves.

opw-5963829

### Steps to reproduce:

- In the settings Enable: "Automatic accounting"
- Create a storable kit product with a storable component both invoiced on delivered qty and in an "automated" ('real_time') inventory valuation.
- Create a kit product with a component invoiced on delivered qty
- Create and confirm a sale order for 1 units of your kit
- On the delivery add a new move for 1 unit of your kit and save
#### > The new line should be exploded into the component
- Set the quantity on both moves and validate
- On the sale order > Create draft invoice > confirm
#### > User Error: The unit of measure Units defined on the order line doesn't belong to the same category as the unit of measure False defined on the product. Please correct the unit of measure defined on the order line or on the product. They should belong to the same category.

### Cause of the issue:

The issue occurs when the `_stock_account_get_anglo_saxon_price_unit` is launched on the account move line created for the extra component because the moves where generated from a kit and hence are associated with a `bom_line_id` but the the product it self is not a kit so that no bom will be found here:
https://github.com/odoo/odoo/blob/521111d50e9119a6286e4b0e236161b1b898f072/addons/sale_mrp/models/account_move.py#L12-L23 In particular, the rest of the call that tries to treat it as a kit will fail because no bom is and should be provided to this line: https://github.com/odoo/odoo/blob/521111d50e9119a6286e4b0e236161b1b898f072/addons/sale_mrp/models/account_move.py#L34

opw-6041375

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

When using test tags for js tests, some tests are not parsed correctly when containing brackets `[ ]`

This is because the tag selector use them to set parameters bounds as in `.test_method[test_param]`

The previous implementation using a regex could generate invalid test tags when the params contains comma, and brackets

This commits fixes this two ways:

Nested brackets will work, meaning that something like `.test_method[test, witch brackets[]]` will be correctly parsed as a tag `.test_method` with a parameter `test, witch brackets[]`since the brakets are balanced. Before, it was parsed as twho tags, `.test_method[test` and ` witch brackets[]]` the second one being considered invalid and spamming logs with errors

Brackets and backslashes can be escaped with a backslash, meaning that something like `.test_method[test, with brackets], and backslash\]` can be escaped as `.test_method[test, with brackets\], and backslash\\]`

Note that the parser will make it's best effort to parse non escaped strings, so a \ not followed by and escaped character will remain there in order to make potential copy paste easier. For the previous example
`.test_method[test, with brackets\], and backslash\` will work the same way.

So in practice, we only really need to escape \ when followed by another backslash or a bracket, and we need to escape brackets when they are not balanced.

Comma in hoot tests are also a problem since they are used to separate parameters, this can easily be tested by only splitting on `,@` since all hoot test should start with a @ and parameters of test_unit_* tests should be a list of hoot tests.

A followup pr will introduce the params to the canonical tag, and escape it as needed