Currently, when a user without accounting permissions attempts to cancel a Manufacturing Order (MO), an Access Error is raised.

## Steps to produce:
- Install Manufacturing and Accounting with demo data.
- Users > Marc Demo > Remove Accounting Permissions and give Admin permissions for Manufacturing
- Login as Marc Demo
- Create an MO for` [D_0045_G] Stool (Green) `and try to cancel it.

## Observed Behavior:
Failed to read field mrp.workorder.employee_analytic_account_line_ids

## Root cause:
After PR [1], version 19.0 introduced access checks when reading many2many fields. As a result, if a user lacks read access to a model field, an access error is raised.

During cancellation, `action_cancel` [2] is called, and the error occurs when unlinking, since the user does not have read access to the account.analytic.line records the system throws an access error.

**Why does this error not occur in 19.3+?**
Commit [3] added `sudo` to allow cancellation of workorder
[2]:
https://github.com/odoo/enterprise/blob/d7ab7ee1287342638006e290ede20b955aae8370/mrp_workorder_hr_account/models/mrp_workorder.py#L24-L26
 
## Solution:
Manufacturing Administrators often need to cancel MOs and WOs, but granting them accounting rights solely for this purpose is not always necessary. A practical solution is to allow MO cancellation through sudo privileges, which can be achieved by backporting [3].

[1]:
https://github.com/odoo/odoo/pull/217277

[3]:
https://github.com/odoo/enterprise/commit/31cf5f014c48b97158042e64ad0b8e9827a6c0d5

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

opw-6204049

Forward-Port-Of: odoo/enterprise#118950

During Intrastat CSV export, fields `supplementary_units` formatted using [formatLang](https://github.com/odoo/enterprise/pull/81711/changes), which converts numeric values into strings (e.g., '84,0'). These string values are later reused in computations, leading to errors like:
```.py
File "/home/odoo/src/enterprise/19.0/l10n_nl_intrastat/models/account_intrastat_report.py", line 163, in l10n_nl_export_to_csv
    supp_unit = str(round(res['supplementary_units'])).zfill(10) if res['supplementary_units'] else '0000000000'
TypeError: type str doesn't define __round__ method
```
https://github.com/odoo/enterprise/blob/2bfe0f32c0cec426fc7345ef716395146cc569ca/l10n_nl_intrastat/models/account_intrastat_report.py#L164 This occurs because the export logic expects numeric values, but receives localized strings or None.

Cause:
`formatLang` is applied at the report data level, converting floats into locale-formatted strings. These values are then used directly in arithmetic operations without normalization.

Fix:
Normalize values before computation by:
- Converting input to string
- Replacing locale-specific decimal separators (',' -> '.')
- Casting to float
- Falling back to 0 when value is None or empty

opw-6182286

Forward-Port-Of: odoo/enterprise#116166

*= test_l10n_us_hr_payroll_account

The employer matching cap for pre-retirement plans (401KMATCHING) evaluates to zero for hourly wage employees if wage is set to zero.

### **Steps to Reproduce:**
1) Install l10n_us_hr_payroll.
2) Create an employee with an hourly wage and set the fixed wage to 0. 
3) Configure the retirement plan parameters as follows:
  - 401(k) = 3%
  - Matching Amount = 100%
  - Matching Yearly Cap = 100% 
4) Generate a payslip for this employee and compute the sheet.

### **Observed Behavior:**
The "Benefits Matching to Retirement Plans" line computes as zero for the hourly employee.

### **Expected Behavior:**
The employer matching contribution should dynamically scale based on the actual gross pay period earnings instead of evaluating to zero.

### **Root Cause:**
The calculation of `partial_cap` uses `version.wage` directly at [1]. For hourly employees, the fixed 'wage' field defaults to zero, causing the entire multiplication to cancel out.

[1]- https://github.com/odoo/enterprise/blob/4c540f450d4de8b59b871662123f85ed54cca2a9/l10n_us_hr_payroll/data/hr_salary_rule_data.xml#L167

### **Fix:**
This commit computes the retirement matching eligibility cap from
`gross annualized wages` and applies the employer matching percentage on
the eligible contribution amount. This ensures retirement matching is
calculated consistently regardless of the employee's contract type.

**opw-6181024**

Forward-Port-Of: odoo/enterprise#120570
Forward-Port-Of: odoo/enterprise#119370

Steps to reproduce:
----------------------------------------
- Create two rules in an overtime ruleset:
    - Non-working hours rule: 
        - Timing
         - Outside of a specific schedule
         - Select a schedule working Monday to Friday
    - Weekend rule:
        - Timing
        - On any non-working day
- Give this ruleset to an employee
- Create an attendance for this employee
    - from 21pm on Friday
    - to 4am on Saturday, the next day
- Check the overtime lines of the attendance
- There is only one overtime line for the first rule

Cause:
----------------------------------------
In the overtime refactor 49952e57ab2e8af908112fa77acd22a5e26fa627 the method `_get_dates()` was introduced to get the dates which an attendance overlap.

It uses `rrule()` to create a list of datetime:
`list(rrule(DAILY, dtstart=localized_start, until=localized_end))`

But `rrule` is returning a new date every 24 hours after the time given in `dtstart`. In our example only the datetime onat 21pm on Friday is returned. If it was ending after 21pm on Friday this time would also be returned.

These dates are given as `min_check_in` and `max_check_out`. So later these dates are used to calculate the non-working days:

https://github.com/odoo/odoo/blob/8d14665af5acf1bd391d05a5048dc701986e8b15/addons/hr_attendance/models/hr_attendance_overtime_rule.py#L441-L448

Only Friday is returned, so the second rule is ignored.

Solution:
----------------------------------------
We use `date()` when calling `rrule()` so the hours are ignored.

This has no impact as `min_check_in` and `max_check_out` are always used later with `datetime.combine(min_check_in, datetime.min.time())`.

opw-6159674

Forward-Port-Of: odoo/odoo#267202

Currently, when a user without accounting permissions attempts to duplicate a Manufacturing Order (MO), an Access Error is raised.

## Steps to produce:
- Install Manufacturing and Accounting with demo data.
- Users > Marc Demo > Remove Accounting Permissions and give Admin permissions for Manufacturing
- Login as Marc Demo
- Create an MO and try to duplicate it.

## Observed Behavior:
An Access Error is displayed saying failed to read mrp.production.wip_move_ids

## Root cause:
After PR [1], version 19.0 introduced access checks when reading many2many fields. As a result, if a user lacks read access to a model field, an access error is raised during record duplication.

During duplication, `copy_data` is called, and the error occurs when invoking the super method at [2], because the user does not have read access to the `wip_move_ids` field on account.move.

**Why does this error not occur in 19.3+?**
Commit [3] prevents the `wip_move_ids` field from being copied, which avoids triggering the access check and therefore prevents this error.

[2]-
https://github.com/odoo/odoo/blob/a2f072fe99a03aaf521bba1965e7f29a1c99e325/addons/mrp/models/mrp_production.py#L1135-L1137 

## Solution:
Prevent copying the `wip_move_ids` fields because, as noted in commit [3], it does not make sense to carry over work-in-progress journal entries from a previous Manufacturing Order to a newly duplicated one.

WIP entries represent accounting values for partially completed goods tied to the original Manufacturing Order, so duplicating those links is both functionally incorrect and can trigger the access error described above.

[1]:
https://github.com/odoo/odoo/pull/217277

[3]:
https://github.com/odoo/odoo/pull/251731/changes/27b5d5551cc772f238695768478a448da75cac61

Related enterprise PR: https://github.com/odoo/enterprise/pull/118950

opw-6204049

Forward-Port-Of: odoo/odoo#264925

Steps to reproduce
1. Set warehouse to 2-step incoming (Input → Stock)
2. Enable "Propagation of carrier" on the push rule (Input → Stock)
3. On the vendor, set "Purchase Orders Grouping" to "Always"
4. Create a storable product with the Buy route and that vendor
5. Create two sale orders for that product, each with a different delivery carrier
6. Confirm both sale orders → a single merged purchase order is created
7. Confirm the purchase order → a receipt (Vendors → Input) is created
8. Validate the receipt → ValueError: Expected singleton: delivery.carrier(1, 3)

Issue
In `_get_new_picking_values`, when the push rule fires to create the internal transfer (Input → Stock), the carrier is fetched from the referenced sale orders: carrier_id = self.reference_ids.sale_ids.carrier_id.id https://github.com/odoo/odoo/blob/5fb0c1f1460949043aa23ddbed09bdbfdc4a8482/addons/stock_delivery/models/stock_move.py#L45

Because both sale orders share the same merged receipt, the receipt move references both. When those SOs have different carriers, `self.reference_ids.sale_ids.carrier_id` returns a multi-record recordset and calling `.id` raises `ValueError: Expected singleton: delivery.carrier(1, 3)`.

opw-6126760

Forward-Port-Of: odoo/odoo#270168
Forward-Port-Of: odoo/odoo#262671

*=l10n_ch_hr_payroll,hr_payroll_account_iso20022

When clicking the create payment report button on a payslip for a Swiss company,
a traceback occurs if the ``hr_payroll_account_iso20022`` module is not installed.

Steps to reproduce the error:
- Install ``l10n_ch_hr_payroll`` module
- Switch to CH Company
- Create an Employee and running contract for it
- Go to Payroll > Payslip > All payslips > Create a new payslip > Set the employee > Confirm > Create payment report

Traceback:
```py
ValueError: Wrong value for hr.payroll.payment.report.wizard.export_format: 'iso20022_ch'
```

https://github.com/odoo/enterprise/blob/7792926504a823590fbbe574a96994002a92fc17/l10n_ch_hr_payroll/models/hr_payslip.py#L383 https://github.com/odoo/enterprise/blob/7792926504a823590fbbe574a96994002a92fc17/l10n_ch_hr_payroll/models/hr_payslip_run.py#L13
Here, ``iso20022_ch`` is passed as ``export_format``,
However, ``iso20022_ch`` is added to the selection field in the ``hr_payroll_account_iso20022`` module at [1].
When that module is not installed, the selection value does not exist, leading to the above error.

[1]: https://github.com/odoo/enterprise/blob/7792926504a823590fbbe574a96994002a92fc17/hr_payroll_account_iso20022/wizard/hr_payroll_payment_report_wizard.py#L11

sentry-7391832811

Forward-Port-Of: odoo/enterprise#120699
Forward-Port-Of: odoo/enterprise#113277

During Intrastat CSV export, fields `supplementary_units` formatted using [formatLang](https://github.com/odoo/enterprise/pull/81711/changes), which converts numeric values into strings (e.g., '84,0'). These string values are later reused in computations, leading to errors like:
```.py
File "/home/odoo/src/enterprise/19.0/l10n_nl_intrastat/models/account_intrastat_report.py", line 163, in l10n_nl_export_to_csv
    supp_unit = str(round(res['supplementary_units'])).zfill(10) if res['supplementary_units'] else '0000000000'
TypeError: type str doesn't define __round__ method
```
https://github.com/odoo/enterprise/blob/2bfe0f32c0cec426fc7345ef716395146cc569ca/l10n_nl_intrastat/models/account_intrastat_report.py#L164 This occurs because the export logic expects numeric values, but receives localized strings or None.

Cause:
`formatLang` is applied at the report data level, converting floats into locale-formatted strings. These values are then used directly in arithmetic operations without normalization.

Fix:
Normalize values before computation by:
- Converting input to string
- Replacing locale-specific decimal separators (',' -> '.')
- Casting to float
- Falling back to 0 when value is None or empty

opw-6182286

Forward-Port-Of: odoo/enterprise#116166

*=l10n_ch_hr_payroll,hr_payroll_account_iso20022

When clicking the create payment report button on a payslip for a Swiss company,
a traceback occurs if the ``hr_payroll_account_iso20022`` module is not installed.

Steps to reproduce the error:
- Install ``l10n_ch_hr_payroll`` module
- Switch to CH Company
- Create an Employee and running contract for it
- Go to Payroll > Payslip > All payslips > Create a new payslip > Set the employee > Confirm > Create payment report

Traceback:
```py
ValueError: Wrong value for hr.payroll.payment.report.wizard.export_format: 'iso20022_ch'
```

https://github.com/odoo/enterprise/blob/7792926504a823590fbbe574a96994002a92fc17/l10n_ch_hr_payroll/models/hr_payslip.py#L383 https://github.com/odoo/enterprise/blob/7792926504a823590fbbe574a96994002a92fc17/l10n_ch_hr_payroll/models/hr_payslip_run.py#L13
Here, ``iso20022_ch`` is passed as ``export_format``,
However, ``iso20022_ch`` is added to the selection field in the ``hr_payroll_account_iso20022`` module at [1].
When that module is not installed, the selection value does not exist, leading to the above error.

[1]: https://github.com/odoo/enterprise/blob/7792926504a823590fbbe574a96994002a92fc17/hr_payroll_account_iso20022/wizard/hr_payroll_payment_report_wizard.py#L11

sentry-7391832811

Forward-Port-Of: odoo/enterprise#120433
Forward-Port-Of: odoo/enterprise#113277

Currently, when a user without accounting permissions attempts to duplicate a Manufacturing Order (MO), an Access Error is raised.

## Steps to produce:
- Install Manufacturing and Accounting with demo data.
- Users > Marc Demo > Remove Accounting Permissions and give Admin permissions for Manufacturing
- Login as Marc Demo
- Create an MO and try to duplicate it.

## Observed Behavior:
An Access Error is displayed saying failed to read mrp.production.wip_move_ids

## Root cause:
After PR [1], version 19.0 introduced access checks when reading many2many fields. As a result, if a user lacks read access to a model field, an access error is raised during record duplication.

During duplication, `copy_data` is called, and the error occurs when invoking the super method at [2], because the user does not have read access to the `wip_move_ids` field on account.move.

**Why does this error not occur in 19.3+?**
Commit [3] prevents the `wip_move_ids` field from being copied, which avoids triggering the access check and therefore prevents this error.

[2]-
https://github.com/odoo/odoo/blob/a2f072fe99a03aaf521bba1965e7f29a1c99e325/addons/mrp/models/mrp_production.py#L1135-L1137 

## Solution:
Prevent copying the `wip_move_ids` fields because, as noted in commit [3], it does not make sense to carry over work-in-progress journal entries from a previous Manufacturing Order to a newly duplicated one.

WIP entries represent accounting values for partially completed goods tied to the original Manufacturing Order, so duplicating those links is both functionally incorrect and can trigger the access error described above.

[1]:
https://github.com/odoo/odoo/pull/217277

[3]:
https://github.com/odoo/odoo/pull/251731/changes/27b5d5551cc772f238695768478a448da75cac61

Related enterprise PR: https://github.com/odoo/enterprise/pull/118950

opw-6204049

Forward-Port-Of: odoo/odoo#264925

Currently, when a user without accounting permissions attempts to cancel a Manufacturing Order (MO), an Access Error is raised.

## Steps to produce:
- Install Manufacturing and Accounting with demo data.
- Users > Marc Demo > Remove Accounting Permissions and give Admin permissions for Manufacturing
- Login as Marc Demo
- Create an MO for` [D_0045_G] Stool (Green) `and try to cancel it.

## Observed Behavior:
Failed to read field mrp.workorder.employee_analytic_account_line_ids

## Root cause:
After PR [1], version 19.0 introduced access checks when reading many2many fields. As a result, if a user lacks read access to a model field, an access error is raised.

During cancellation, `action_cancel` [2] is called, and the error occurs when unlinking, since the user does not have read access to the account.analytic.line records the system throws an access error.

**Why does this error not occur in 19.3+?**
Commit [3] added `sudo` to allow cancellation of workorder
[2]:
https://github.com/odoo/enterprise/blob/d7ab7ee1287342638006e290ede20b955aae8370/mrp_workorder_hr_account/models/mrp_workorder.py#L24-L26
 
## Solution:
Manufacturing Administrators often need to cancel MOs and WOs, but granting them accounting rights solely for this purpose is not always necessary. A practical solution is to allow MO cancellation through sudo privileges, which can be achieved by backporting [3].

[1]:
https://github.com/odoo/odoo/pull/217277

[3]:
https://github.com/odoo/enterprise/commit/31cf5f014c48b97158042e64ad0b8e9827a6c0d5

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

opw-6204049

Forward-Port-Of: odoo/enterprise#118950

Steps to reproduce:
--------------------------------------------
1. Install `website_project` module
2. Create a new project
3. Add a customer to the project
4. Go to customer > add email and phone
5. Create a new task in that project:
    * Observe that the customer is the same as the project
6. Go to Website > Contact Us > Edit > Click on submit button
7. Set action to 'Create a Task' and select the created project in 'Project'
8. Click on Save and Open the URL in Incognito Mode
9. Go to the Contact Us page > Fill in the details > Submit
10. Comeback to our window and open tasks of the created project

Observation:
--------------------------------------------
1. A new task is created using the customer details entered in the form.
2. The existing task’s customer and the project’s customer are also incorrectly updated to this new customer.

Issue:
--------------------------------------------
The bug is in the `extract_data` method of the website form controller for projects.
A non-logged-in user submits the Contact Us form with name and an email that doesn't match any existing partner. The old code's `else` branch would set `partner_name` in the task record values without setting a `partner_id` https://github.com/odoo/odoo/blob/cd080047578b9992811608a5af73a982a414da39/addons/website_project/controllers/main.py#L65-L66

During task creation, the computed field `_compute_partner_id` automatically sets `partner_id` to the project's partner
https://github.com/odoo/odoo/blob/cd080047578b9992811608a5af73a982a414da39/addons/project/models/project_task.py#L1440-L1441

`partner_name` is defined as
https://github.com/odoo/odoo/blob/cd080047578b9992811608a5af73a982a414da39/addons/website_project/models/project_task.py#L12

In Odoo, a related field is essentially a shortcut to a field on a linked record The key attribute here is `readonly=False`. This tells Odoo:
    * On read: Get the value from `self.partner_id.name`
    * On write: Propagate the write back to `self.partner_id.name` (this is the inverse). So writing `task.partner_name = 'TEST'` is equivalent to writing `task.partner_id.name = 'TEST'`. It modifies the partner record itself, not just the task.

So, the partner record itself was renamed. Every record that references a partner now sees the new name

Solution:
--------------------------------------------
The fix passes `False` to `partner_id`, this way:
    * The existing partner is untouched
    * All other tasks and the sales order keep their correct customer

opw-6206080

Forward-Port-Of: odoo/odoo#264738

Steps to reproduce:
----------------------------------------
- Create two rules in an overtime ruleset:
    - Non-working hours rule: 
        - Timing
         - Outside of a specific schedule
         - Select a schedule working Monday to Friday
    - Weekend rule:
        - Timing
        - On any non-working day
- Give this ruleset to an employee
- Create an attendance for this employee
    - from 21pm on Friday
    - to 4am on Saturday, the next day
- Check the overtime lines of the attendance
- There is only one overtime line for the first rule

Cause:
----------------------------------------
In the overtime refactor 49952e57ab2e8af908112fa77acd22a5e26fa627 the method `_get_dates()` was introduced to get the dates which an attendance overlap.

It uses `rrule()` to create a list of datetime:
`list(rrule(DAILY, dtstart=localized_start, until=localized_end))`

But `rrule` is returning a new date every 24 hours after the time given in `dtstart`. In our example only the datetime onat 21pm on Friday is returned. If it was ending after 21pm on Friday this time would also be returned.

These dates are given as `min_check_in` and `max_check_out`. So later these dates are used to calculate the non-working days:

https://github.com/odoo/odoo/blob/8d14665af5acf1bd391d05a5048dc701986e8b15/addons/hr_attendance/models/hr_attendance_overtime_rule.py#L441-L448

Only Friday is returned, so the second rule is ignored.

Solution:
----------------------------------------
We use `date()` when calling `rrule()` so the hours are ignored.

This has no impact as `min_check_in` and `max_check_out` are always used later with `datetime.combine(min_check_in, datetime.min.time())`.

opw-6159674

Forward-Port-Of: odoo/odoo#267202

Steps to reproduce
1. Set warehouse to 2-step incoming (Input → Stock)
2. Enable "Propagation of carrier" on the push rule (Input → Stock)
3. On the vendor, set "Purchase Orders Grouping" to "Always"
4. Create a storable product with the Buy route and that vendor
5. Create two sale orders for that product, each with a different delivery carrier
6. Confirm both sale orders → a single merged purchase order is created
7. Confirm the purchase order → a receipt (Vendors → Input) is created
8. Validate the receipt → ValueError: Expected singleton: delivery.carrier(1, 3)

Issue
In `_get_new_picking_values`, when the push rule fires to create the internal transfer (Input → Stock), the carrier is fetched from the referenced sale orders: carrier_id = self.reference_ids.sale_ids.carrier_id.id https://github.com/odoo/odoo/blob/5fb0c1f1460949043aa23ddbed09bdbfdc4a8482/addons/stock_delivery/models/stock_move.py#L45

Because both sale orders share the same merged receipt, the receipt move references both. When those SOs have different carriers, `self.reference_ids.sale_ids.carrier_id` returns a multi-record recordset and calling `.id` raises `ValueError: Expected singleton: delivery.carrier(1, 3)`.

opw-6126760

Forward-Port-Of: odoo/odoo#270168
Forward-Port-Of: odoo/odoo#262671

During Intrastat CSV export, fields `supplementary_units` formatted using [formatLang](https://github.com/odoo/enterprise/pull/81711/changes), which converts numeric values into strings (e.g., '84,0'). These string values are later reused in computations, leading to errors like:
```.py
File "/home/odoo/src/enterprise/19.0/l10n_nl_intrastat/models/account_intrastat_report.py", line 163, in l10n_nl_export_to_csv
    supp_unit = str(round(res['supplementary_units'])).zfill(10) if res['supplementary_units'] else '0000000000'
TypeError: type str doesn't define __round__ method
```
https://github.com/odoo/enterprise/blob/2bfe0f32c0cec426fc7345ef716395146cc569ca/l10n_nl_intrastat/models/account_intrastat_report.py#L164 This occurs because the export logic expects numeric values, but receives localized strings or None.

Cause:
`formatLang` is applied at the report data level, converting floats into locale-formatted strings. These values are then used directly in arithmetic operations without normalization.

Fix:
Normalize values before computation by:
- Converting input to string
- Replacing locale-specific decimal separators (',' -> '.')
- Casting to float
- Falling back to 0 when value is None or empty

opw-6182286

Forward-Port-Of: odoo/enterprise#116166

Currently, when a user without accounting permissions attempts to duplicate a Manufacturing Order (MO), an Access Error is raised.

## Steps to produce:
- Install Manufacturing and Accounting with demo data.
- Users > Marc Demo > Remove Accounting Permissions and give Admin permissions for Manufacturing
- Login as Marc Demo
- Create an MO and try to duplicate it.

## Observed Behavior:
An Access Error is displayed saying failed to read mrp.production.wip_move_ids

## Root cause:
After PR [1], version 19.0 introduced access checks when reading many2many fields. As a result, if a user lacks read access to a model field, an access error is raised during record duplication.

During duplication, `copy_data` is called, and the error occurs when invoking the super method at [2], because the user does not have read access to the `wip_move_ids` field on account.move.

**Why does this error not occur in 19.3+?**
Commit [3] prevents the `wip_move_ids` field from being copied, which avoids triggering the access check and therefore prevents this error.

[2]-
https://github.com/odoo/odoo/blob/a2f072fe99a03aaf521bba1965e7f29a1c99e325/addons/mrp/models/mrp_production.py#L1135-L1137 

## Solution:
Prevent copying the `wip_move_ids` fields because, as noted in commit [3], it does not make sense to carry over work-in-progress journal entries from a previous Manufacturing Order to a newly duplicated one.

WIP entries represent accounting values for partially completed goods tied to the original Manufacturing Order, so duplicating those links is both functionally incorrect and can trigger the access error described above.

[1]:
https://github.com/odoo/odoo/pull/217277

[3]:
https://github.com/odoo/odoo/pull/251731/changes/27b5d5551cc772f238695768478a448da75cac61

Related enterprise PR: https://github.com/odoo/enterprise/pull/118950

opw-6204049

Forward-Port-Of: odoo/odoo#264925

Currently, when a user without accounting permissions attempts to cancel a Manufacturing Order (MO), an Access Error is raised.

## Steps to produce:
- Install Manufacturing and Accounting with demo data.
- Users > Marc Demo > Remove Accounting Permissions and give Admin permissions for Manufacturing
- Login as Marc Demo
- Create an MO for` [D_0045_G] Stool (Green) `and try to cancel it.

## Observed Behavior:
Failed to read field mrp.workorder.employee_analytic_account_line_ids

## Root cause:
After PR [1], version 19.0 introduced access checks when reading many2many fields. As a result, if a user lacks read access to a model field, an access error is raised.

During cancellation, `action_cancel` [2] is called, and the error occurs when unlinking, since the user does not have read access to the account.analytic.line records the system throws an access error.

**Why does this error not occur in 19.3+?**
Commit [3] added `sudo` to allow cancellation of workorder
[2]:
https://github.com/odoo/enterprise/blob/d7ab7ee1287342638006e290ede20b955aae8370/mrp_workorder_hr_account/models/mrp_workorder.py#L24-L26
 
## Solution:
Manufacturing Administrators often need to cancel MOs and WOs, but granting them accounting rights solely for this purpose is not always necessary. A practical solution is to allow MO cancellation through sudo privileges, which can be achieved by backporting [3].

[1]:
https://github.com/odoo/odoo/pull/217277

[3]:
https://github.com/odoo/enterprise/commit/31cf5f014c48b97158042e64ad0b8e9827a6c0d5

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

opw-6204049

Forward-Port-Of: odoo/enterprise#118950

Steps to reproduce:
----------------------------------------
- Create two rules in an overtime ruleset:
    - Non-working hours rule: 
        - Timing
         - Outside of a specific schedule
         - Select a schedule working Monday to Friday
    - Weekend rule:
        - Timing
        - On any non-working day
- Give this ruleset to an employee
- Create an attendance for this employee
    - from 21pm on Friday
    - to 4am on Saturday, the next day
- Check the overtime lines of the attendance
- There is only one overtime line for the first rule

Cause:
----------------------------------------
In the overtime refactor 49952e57ab2e8af908112fa77acd22a5e26fa627 the method `_get_dates()` was introduced to get the dates which an attendance overlap.

It uses `rrule()` to create a list of datetime:
`list(rrule(DAILY, dtstart=localized_start, until=localized_end))`

But `rrule` is returning a new date every 24 hours after the time given in `dtstart`. In our example only the datetime onat 21pm on Friday is returned. If it was ending after 21pm on Friday this time would also be returned.

These dates are given as `min_check_in` and `max_check_out`. So later these dates are used to calculate the non-working days:

https://github.com/odoo/odoo/blob/8d14665af5acf1bd391d05a5048dc701986e8b15/addons/hr_attendance/models/hr_attendance_overtime_rule.py#L441-L448

Only Friday is returned, so the second rule is ignored.

Solution:
----------------------------------------
We use `date()` when calling `rrule()` so the hours are ignored.

This has no impact as `min_check_in` and `max_check_out` are always used later with `datetime.combine(min_check_in, datetime.min.time())`.

opw-6159674

Forward-Port-Of: odoo/odoo#267202

### Steps to reproduce:

- In the settings enable: Multi-Steps Routes
- Put your warehouse in delivery in 2 steps
- On the receipt operation type change the return operation type to be "pick" by default.
- Create and confirm a PO for 1 unit of P
- Validate the receipt > return > Create the return for 1 unit
- Change the operation type of the return from Pick to Delivery to return the product in one step.
- Validate the return
#### > The qty_received is updated from 1 to 2 instead of 0.

### Cause of the issue:

Updating the `picking_type_id` of the return will also update the `location_dest_id` to the default values:
https://github.com/odoo/odoo/blob/89807c10c20fb533124b18815f307fc3c380528d/addons/stock/models/stock_picking.py#L1138-L1147
However, the default values of the `Delivery` is "Partner/customer". As such, the location dest of the move is also updated to be "Partner/customer". Now the issue is that the `qty_received` only considers moves to be returned if the location dest usage is not 'supplier':
https://github.com/odoo/odoo/blob/89807c10c20fb533124b18815f307fc3c380528d/addons/purchase/models/purchase_order_line.py#L226-L231 https://github.com/odoo/odoo/blob/89807c10c20fb533124b18815f307fc3c380528d/addons/purchase_stock/models/purchase_order_line.py#L55-L67 https://github.com/odoo/odoo/blob/89807c10c20fb533124b18815f307fc3c380528d/addons/purchase_stock/models/purchase_order_line.py#L76-L77 https://github.com/odoo/odoo/blob/89807c10c20fb533124b18815f307fc3c380528d/addons/purchase_stock/models/stock_move.py#L129-L131

opw-6292918

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

Forward-Port-Of: odoo/odoo#269867

## Issue
When trying to call `dt.replace` on a `datetime.time`, a TypeError is raised

```
File "/home/odoo/Documents/src/odoo/190/odoo/addons/base/models/ir_sequence.py", line 270, in _next
    return seq_date.with_context(ir_sequence_date_range=seq_date.date_from, ir_sequence_date=dt.replace(tzinfo=None))._next()
                                                                                             ^^^^^^^^^^^^^^^^^^^^^^^
TypeError: 'tzinfo' is an invalid keyword argument for replace()
```

## Steps to reproduce
1. Install *Accounting* (`accountant`)
2. Update the `account.payment` sequence:
    - Toggle *Use subsequences per date_range* and create a range
3. In Accounting > Customers > Payments, create a payment:
    - Payment Type: Receive
    - Customer: Any
    - Amount: Any
4. **A traceback appears**

## Cause
This error was introduced by https://github.com/odoo/odoo/commit/4b9dd7893f96.

The `AccountPayment._compute_name` method calls `_next_by_code` and passes a date as the `sequence_date`.

https://github.com/odoo/odoo/blob/337efb069f6cf2cb9478a970f075fd139c1e8e0a/addons/account/models/account_payment.py#L420-L422

In the `_next` method, the `dt` variable is set to that date (`datetime.date`), and calling the `.replace` method on that variable raises an error, as there's no tzinfo for `datetime.date`s.

opw-6303885

Forward-Port-Of: odoo/odoo#270283

**Issue**
In subcontracting, deleting a raw move line and adding a new one in the same editing flow can lead to a validation error during production recording.

**Steps to reproduce**
- Create a subcontracting product with a comp A
- Create and confirm a purchase order of that product (with the subcontracting partner)
- Open the associated delivery
- Open the move details (hamburger button)
- Delete the move line linked to the comp A
- Create a new move line for a comp B with a quantity of 1
- Record the production
-> A validation error occurs: the mandatory field `product_uom_id` is not set.

**Cause**
The regression comes from this commit: https://github.com/odoo/odoo/commit/54f10b56f577ad9ed5575bd396dba7d20d22fc2e

While assigning `move_raw_ids`, the inverse method is triggered:
https://github.com/odoo/odoo/blob/9267b2d1a9b2d2d6a33eceab07d572406c68c723/addons/mrp_subcontracting/models/mrp_production.py#L34
At this stage, newly added lines are still virtual records (`line`):
https://github.com/odoo/odoo/blob/9267b2d1a9b2d2d6a33eceab07d572406c68c723/addons/mrp_subcontracting/models/mrp_production.py#L38
The previous implementation directly unlinked removed move lines (see commit https://github.com/odoo/odoo/commit/54f10b56f577ad9ed5575bd396dba7d20d22fc2e):
https://github.com/odoo/odoo/blob/9267b2d1a9b2d2d6a33eceab07d572406c68c723/addons/mrp_subcontracting/models/mrp_production.py#L40-L43
Which will eventually flush and invalidate all the cache:
https://github.com/odoo/odoo/blob/0e78b4fd2ab904f2e12107cb6ff7cc11d512259f/odoo/models.py#L4666
And since `line` is a virtual record (not in db), its associated values will be reset, among those, `product_uom_id`.
Later, when the move line is reassigned:
https://github.com/odoo/odoo/blob/0e78b4fd2ab904f2e12107cb6ff7cc11d512259f/addons/mrp_subcontracting/models/mrp_production.py#L49
https://github.com/odoo/odoo/blob/0e78b4fd2ab904f2e12107cb6ff7cc11d512259f/odoo/models.py#L5223-L5228

the validation fails because the virtual line no longer contains the required values.

**Additional note**
An alternative could have been using Command but since this line:
https://github.com/odoo/odoo/blob/0e78b4fd2ab904f2e12107cb6ff7cc11d512259f/addons/mrp_subcontracting/models/mrp_production.py#L42
can not be converted to:
`Command.set([line.id for line in lines])`
because `lines` may also contain virtual records.
This causes an invalid quantity for the move. Indeed, even if the command operator would update the quantity
on the `move_line` correctly, it won't for the quantity of the `move` because of its associated compute method:
https://github.com/odoo/odoo/blob/26ba95ac1c5bbb24975efb1a6f53c1ab47b61532/addons/stock/models/stock_move.py#L399-L400
that relies on `.ids`, which is `[]` on virtual records.
Therefore, keep the change minimal.

opw-6133281

Forward-Port-Of: odoo/odoo#267279
Forward-Port-Of: odoo/odoo#263058

### Steps to reproduce:

- Enable rental transfer
- Create a rentable product R
- Create and confirm a rental order for 1 unit of R
- Create a kit bom for R: 1 x COMP
- Validate the delivery of your unit of R
#### > Missing Error: Record does not exist or has been deleted.

### Cause of the issue:

Confirming your rental order will generate a confirm moves of R. However, since at this point the product was not a kit, these will not be exploded. Now, the issue is that at validation The move will be exploded and deleted in the super call:
https://github.com/odoo/enterprise/blob/7cceddaf086d849b8e2121e1023ef3479397534f/sale_mrp_renting/models/stock_move.py#L10-L13 https://github.com/odoo/odoo/blob/0f2f222a431627a672daf10c86ec2578a27f97bb/addons/mrp/models/stock_move.py#L550-L555 https://github.com/odoo/odoo/blob/0f2f222a431627a672daf10c86ec2578a27f97bb/addons/mrp/models/stock_move.py#L591-L593 However, since the overrides of the sale_{mrp,stock}_renting modules call self rather than the result of the super call, they still expect to work with the original move rather than its exploded result: https://github.com/odoo/enterprise/blob/7cceddaf086d849b8e2121e1023ef3479397534f/sale_mrp_renting/models/stock_move.py#L10-L13 https://github.com/odoo/enterprise/blob/7cceddaf086d849b8e2121e1023ef3479397534f/sale_stock_renting/models/stock_move.py#L61-L65

opw-6191841

Forward-Port-Of: odoo/enterprise#120640
Forward-Port-Of: odoo/enterprise#120051

*: hr_holidays,test_discuss_full

**Steps to reproduce,**
Create an employee linked to a user
Archive the employee and remove the link to the user
Create another employee for the same user
Go to Discuss > 'General' channel
Open the member list and click on the user's avatar

**Before this commit,**
Clicking on the avatar opened a popover showing outdated information from the
archived employee record instead of the new one.

**Cause,**
By default, the server sends employee data ordered by name. Since both records
have the same name, the order is non-deterministic. The client then attempts to
match the employee's company to the current user's company, falling back to the
first record in the list if no match is found.

**Fix,**
Filter out archived records first (treating them as non-existent). Then, sort
the remaining employee records to prioritize those that match the current user's
active company. In case records share the same company, prioritize employees
with a related user. Fall back to descending order of creation for identical
results.

**After this commit,**
Clicking on the avatar shows the correct employee details in the popover.

task-6175765

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

Forward-Port-Of: odoo/odoo#252170

## [FIX] sale_renting_planning: check global leaves working schedule

Before this commit: any `resource.calendar.leaves` with no `resource_id` created would prevent all resources from being allocated during the leave date.

After this commit: any `resource.calendar.leaves` with `no resource_id` would be applied only to resources with the same `calendar_id` as the leave.

if the leave has no `calendar_id` then the leave applies to all `resource.calendars`

if a resource has no `calendar_id` then leaves with no `calendar_id` apply to it as well

## [IMP] {website_}sale_renting_planning: move tests from industry and fix existing ones

This commit moves the tests from [odoo/industry#1980](vscode-file://vscode-app/snap/code/237/usr/share/code/resources/app/out/vs/code/electron-browser/workbench/workbench.html) to their respective standard modules.

It also fixes the logic behind some tests as they weren't testing a `planning.role` with `sync_shift_rental` enabled.

task-6179505

Forward-Port-Of: odoo/enterprise#116430

### Steps to reproduce:

- Enable rental transfer
- Create a rentable product R
- Create and confirm a rental order for 1 unit of R
- Create a kit bom for R: 1 x COMP
- Validate the delivery of your unit of R
#### > Missing Error: Record does not exist or has been deleted.

### Cause of the issue:

Confirming your rental order will generate a confirm moves of R. However, since at this point the product was not a kit, these will not be exploded. Now, the issue is that at validation The move will be exploded and deleted in the super call:
https://github.com/odoo/enterprise/blob/7cceddaf086d849b8e2121e1023ef3479397534f/sale_mrp_renting/models/stock_move.py#L10-L13 https://github.com/odoo/odoo/blob/0f2f222a431627a672daf10c86ec2578a27f97bb/addons/mrp/models/stock_move.py#L550-L555 https://github.com/odoo/odoo/blob/0f2f222a431627a672daf10c86ec2578a27f97bb/addons/mrp/models/stock_move.py#L591-L593 However, since the overrides of the sale_{mrp,stock}_renting modules call self rather than the result of the super call, they still expect to work with the original move rather than its exploded result: https://github.com/odoo/enterprise/blob/7cceddaf086d849b8e2121e1023ef3479397534f/sale_mrp_renting/models/stock_move.py#L10-L13 https://github.com/odoo/enterprise/blob/7cceddaf086d849b8e2121e1023ef3479397534f/sale_stock_renting/models/stock_move.py#L61-L65

opw-6191841

Forward-Port-Of: odoo/enterprise#120640
Forward-Port-Of: odoo/enterprise#120051

**Steps to reproduce:**
- Install the `l10n_de` module and switch to a `DE Company`.
- Enable `Peppol` in the Invoicing app settings.
- Open the `DE Company` customer record.
- In the `Invoicing` tab, change the Peppol ID code from `Germany VAT` 
  to `Germany Leitweg-ID` and set a code (e.g., `13075957-K000-52`).
- In the `Contacts & Addresses` tab, create an invoice-type contact named `test`.
- Create a new invoice using the `test` contact.
- Send the invoice via Peppol.
- Download the generated `XML` and inspect the `BuyerReference` field.

**Observation:**
The `<cbc:BuyerReference>` field is set to `N/A` instead of the configured `Leitweg-ID`.

**Root Cause:**
At [1], the `BuyerReference` node is populated using `vals['customer']`. 
For invoices addressed to an invoice-type contact, the contact itself 
does not contain the Peppol configuration, which is stored on the 
commercial partner. As a result, the code fails to retrieve the 
customer's `Leitweg-ID` and leaves the `BuyerReference` field empty.

**Fix:**
This commit ensures that the configured Leitweg-ID is correctly added to the 
`BuyerReference` field for child contact.

[1]:
https://github.com/odoo/odoo/blob/281658e86971687656f3235ac1ff8afcb52f2908/addons/account_edi_ubl_cii/models/account_edi_xml_ubl_xrechnung.py#L87-L97

opw-6269478

Forward-Port-Of: odoo/odoo#269818

Steps to reproduce:
===================
1. Edit a job page.
2. Delete every `s_rating` block.
3. Save.

=> Validation Error: Document is empty.

Cause:
======
Deleting the last snippet inside an editable HTML field (e.g. the last `s_rating` block in the `website_rating` field of a job page) leaves the field's editable container with only whitespace text nodes. On save, it writes that whitespace to the record and then calls `_copy_custom_snippet_translations`, which does
`html.fromstring(lang_value)` on the whitespace and raises `lxml.etree.ParserError: Document is empty`, re-raised as `ValidationError`. The user sees a "Validation Error" dialog and can't finish saving.

The previous fix for the analogous "Document is empty" symptom on product description editing (commit [1])
added a `cleanupEmptyStructures` `on_removed_handlers` that strips whitespace from `.oe_empty` containers after element removal. That selector covers `oe_structure.oe_empty` containers but not editable HTML field savables (`[data-oe-type="html"]`), which don't carry an `oe_empty` class when they originally had content. As a result, fields like `hr.job.website_rating` still hit the failing parse path.

Solution:
=========
Extend the cleanup selector to also include `[data-oe-type="html"]` so HTML-field editables are normalized to genuinely empty after the last inner snippet is removed.

[1]: https://github.com/odoo/odoo/commit/53d5cc7eed635f64038bf0315f6863011879c529

opw-6244892

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

Forward-Port-Of: odoo/odoo#267397

## The Problem
When grouping messages, the code was accumulating recordsets using the `|=` union operator inside a loop. Since each union call internally builds an `OrderedSet` over all previously accumulated IDs, the performance degraded quadratically relative to the number of document records. This caused bottlenecks on databases with large message volumes.

## The Solution
* Replaced the `|=` recordset accumulation with a plain Python dictionary of ordered sets to store IDs per operation, while keeping same behavior.
* Deferred the `browse()` call until after the loop is complete.
* Reduced the overall complexity from **$O(N^2)$** to **$O(N)$**.

---

## Benchmarks
*Tested on a customer database grouping by "Created By" and "Created On":*

| Record Count | Before | After | Improvement |
| :--- | :--- | :--- | :--- |
| **300k records** | 83.00s | **1.00s** | **-99%** |
| **30k records** | 0.60s | 0.25s | (Minor) |

**Note:** The performance gains become exponentially more significant as the record count grows.

**OPW-6123758**

Forward-Port-Of: odoo/odoo#269123
Forward-Port-Of: odoo/odoo#260147

During Intrastat CSV export, fields `supplementary_units` formatted using [formatLang](https://github.com/odoo/enterprise/pull/81711/changes), which converts numeric values into strings (e.g., '84,0'). These string values are later reused in computations, leading to errors like:
```.py
File "/home/odoo/src/enterprise/19.0/l10n_nl_intrastat/models/account_intrastat_report.py", line 163, in l10n_nl_export_to_csv
    supp_unit = str(round(res['supplementary_units'])).zfill(10) if res['supplementary_units'] else '0000000000'
TypeError: type str doesn't define __round__ method
```
https://github.com/odoo/enterprise/blob/2bfe0f32c0cec426fc7345ef716395146cc569ca/l10n_nl_intrastat/models/account_intrastat_report.py#L164 This occurs because the export logic expects numeric values, but receives localized strings or None.

Cause:
`formatLang` is applied at the report data level, converting floats into locale-formatted strings. These values are then used directly in arithmetic operations without normalization.

Fix:
Normalize values before computation by:
- Converting input to string
- Replacing locale-specific decimal separators (',' -> '.')
- Casting to float
- Falling back to 0 when value is None or empty

opw-6182286

Forward-Port-Of: odoo/enterprise#116166

*= test_l10n_us_hr_payroll_account

The employer matching cap for pre-retirement plans (401KMATCHING) evaluates to zero for hourly wage employees if wage is set to zero.

### **Steps to Reproduce:**
1) Install l10n_us_hr_payroll.
2) Create an employee with an hourly wage and set the fixed wage to 0. 
3) Configure the retirement plan parameters as follows:
  - 401(k) = 3%
  - Matching Amount = 100%
  - Matching Yearly Cap = 100% 
4) Generate a payslip for this employee and compute the sheet.

### **Observed Behavior:**
The "Benefits Matching to Retirement Plans" line computes as zero for the hourly employee.

### **Expected Behavior:**
The employer matching contribution should dynamically scale based on the actual gross pay period earnings instead of evaluating to zero.

### **Root Cause:**
The calculation of `partial_cap` uses `version.wage` directly at [1]. For hourly employees, the fixed 'wage' field defaults to zero, causing the entire multiplication to cancel out.

[1]- https://github.com/odoo/enterprise/blob/4c540f450d4de8b59b871662123f85ed54cca2a9/l10n_us_hr_payroll/data/hr_salary_rule_data.xml#L167

### **Fix:**
This commit computes the retirement matching eligibility cap from
`gross annualized wages` and applies the employer matching percentage on
the eligible contribution amount. This ensures retirement matching is
calculated consistently regardless of the employee's contract type.

**opw-6181024**

Forward-Port-Of: odoo/enterprise#120570
Forward-Port-Of: odoo/enterprise#119370

### Steps to reproduce:

- Enable rental transfer
- Create a rentable product R
- Create and confirm a rental order for 1 unit of R
- Create a kit bom for R: 1 x COMP
- Validate the delivery of your unit of R
#### > Missing Error: Record does not exist or has been deleted.

### Cause of the issue:

Confirming your rental order will generate a confirm moves of R. However, since at this point the product was not a kit, these will not be exploded. Now, the issue is that at validation The move will be exploded and deleted in the super call:
https://github.com/odoo/enterprise/blob/7cceddaf086d849b8e2121e1023ef3479397534f/sale_mrp_renting/models/stock_move.py#L10-L13 https://github.com/odoo/odoo/blob/0f2f222a431627a672daf10c86ec2578a27f97bb/addons/mrp/models/stock_move.py#L550-L555 https://github.com/odoo/odoo/blob/0f2f222a431627a672daf10c86ec2578a27f97bb/addons/mrp/models/stock_move.py#L591-L593 However, since the overrides of the sale_{mrp,stock}_renting modules call self rather than the result of the super call, they still expect to work with the original move rather than its exploded result: https://github.com/odoo/enterprise/blob/7cceddaf086d849b8e2121e1023ef3479397534f/sale_mrp_renting/models/stock_move.py#L10-L13 https://github.com/odoo/enterprise/blob/7cceddaf086d849b8e2121e1023ef3479397534f/sale_stock_renting/models/stock_move.py#L61-L65

opw-6191841

Forward-Port-Of: odoo/enterprise#120640
Forward-Port-Of: odoo/enterprise#120051

# Introduction note
This PR fixes two bugs introduced by the same commit :
https://github.com/odoo/enterprise/commit/106d70a1ef0ddbd61a74b7cac82dfce1e316beaa

The original commit fixed multiple issues regarding the display of recurring plans when
the One-time purchase option was enabled, but it also introduced new ones.

Theses new issues are due to multiple new checks on `allow_one_time_sale`, but this
variable only indicates that the One-time purchase option is available to the user, not that
it is actually selected. So the fixes of the original commit works when first loading the page,
but fails when the content of the page is updated.

# Shared steps
- Activate Subscriptions & eCommerce modules
- Create a subscription product, enable 'Accept One-Time' and publish it on the website

# Bug 1
 
## How to reproduce
- Add atleast two recurring plans to the product
- Go to the product page on the website
- Select one of the recurring plans
- Increase the quantity of the product

## The problem
The recurring plan selection is removed

## Cause
The condition `!combination_info.allow_one_time_sale` was added on the `t-att-checked` of the recurring plan selection display. This correctly fixed the issue when first loading the page, but when the user changes the price or the variant, the recurring plan are
recomputed and rerendered :

https://github.com/odoo/enterprise/blob/0b408acbadb2cfcbc844521f3244a06b7ae7be22/website_sale_subscription/static/src/interactions/product_page.js#L37-L40

When that is the case, that condition blocks the proper display of the selected recurring plan.

## Proposed Solution
When loading the recurring plan selection, what defines wich plan is selected is the
`subscription_default_pricing_plan_id` variable, which is based on the
`plan_id` value given in the request to the server :
https://github.com/odoo/enterprise/blob/0b408acbadb2cfcbc844521f3244a06b7ae7be22/website_sale_subscription/models/product_template.py#L222

We make it so if no `plan_id` is sent to the server and `allow_one_time_sale` is
enabled, then the server does not give back any `subscription_default_pricing_plan_id`

opw-6131532

# Bug 2

## How to reproduce
- Add an attribute with values A & B for the product
- Define atleast two recurring plans for the variant with attribute B
- Publish the product
- Go to the product page
- Select the variant with attribute B

## The problem
The recurring plan is not displayed. If the order of the attribute is reversed, then it works as expected.

## Cause
The pricings are correcly sent to the front-end but they are not added to selection because
of the check on  `allow_one_time_sale` :
https://github.com/odoo/enterprise/blob/0b408acbadb2cfcbc844521f3244a06b7ae7be22/website_sale_subscription/static/src/interactions/product_page.js#L42-L50

opw-6132160