## Current behavior:
The user Partner Commissions access rights as All Documents or Own Documents and Purchase access rights as User. With this configuration, the user is unable to create new Purchase Orders, and existing Purchase Orders are also not visible in the Purchase module.

## Expected behavior:
The expected behavior is that the user should be able to create and view Purchase Orders with these access rights. Additionally, clarification is required regarding the purpose of the new Partner Commissions access group.

## Steps to reproduce:
- Go to user and assign Partner Commission rights as All or own document.
- On Purchase, select group as User.

## Cause of the issue:
partner_commission adds commission-specific purchase order record rules, but purchase users have no matching purchase-order rule in that module. For mixed-role users, the commission rule ends up restricting standard purchase orders as well.

## Fix:
Apply the module's explicit all-purchase rule to purchase users so mixed users keep base procurement access while commission-only users remain restricted by the commission rules.

opw-6366074

Forward-Port-Of: odoo/enterprise#126003

## Description

Opening an accounting report containing many lines can trigger Owl's maximum render iteration error, leading to an infinite rendering loop. This could notably occur when navigating from a Profit and Loss report to a General Ledger in multi-company setting or with a few l10n.

`AccountReportLineName` used `asyncComputed` to create the audit status record, although its computation contained no asynchronous operation. Each line therefore published its result after the initial render and scheduled another render. With enough lines, the report exceeded Owl's limit of 1000 render iterations before the DOM could be updated.

This commit uses `computed` instead, allowing the status record to be calculated and cached synchronously. Keep the record construction untracked so its internal reactive state does not become a dependency.

opw-6432000

## Steps to reproduce

- Go on a runbot instance saas-19.4, enterprise build, select all companies, make sure some localications are installed (since we need quite a few lines).
- P&L, select date range the whole year 2026, unfold the Expense account, kebab button -> General Ledger.

If you have enough lines, you will enter an infinite loop in the front-end. Not always obvious to reproduce it. The test provided is deterministic in term of reproduction.

mark_urbanpiper_prep_order_as_printed() raised ValueError when the
'urbanpiper_printed' flag was already set, to stop the same order from
printing its preparation ticket twice (https://github.com/odoo/enterprise/pull/103894,
Task-5353283).

Accepting an UrbanPiper order fires this RPC from two places for the
same order: synchronously from TicketScreen, and again via the
DELIVERY_ORDER_COUNT bus notification the accept flow itself
broadcasts. Under load, both requests race for the row lock; Odoo's
retrying() replays the loser on lock contention, and by the time it
replays the winner has already committed, so the loser hits the
already-printed branch and raises. The raise is an unhandled
ValueError, so it surfaces as a 500 and fails any tour that accepts
an order (test_frontend.py, test_order_receipt.py),
intermittently and CI-timing-dependent only.

The only caller (pos_store.js: _sendDeliveryOrderForPreparation)
already wraps the RPC in try/catch and treats a caught exception
exactly like a falsy return value: either way it just skips sending
the ticket to preparation. No other code reads or writes
urbanpiper_printed, and no webhook path calls this method, so
returning False is behaviorally identical for every real caller and
safe to make the default.

This also removes the mark_urbanpiper_prep_order_as_printed_patch
monkeypatch added alongside the original raise in test_01_order_flow:
it existed solely to swallow this exact ValueError for that one tour,
which is no longer needed now that the method itself is idempotent.

runbot error: 941514

Forward-Port-Of: odoo/enterprise#127467
Forward-Port-Of: odoo/enterprise#125840

## [FIX] timesheet_grid: remove duplicate rpc call

Before this commit, the `loadTimesheets` method is called 2 times in a
row, that method does a rpc call to load the existing timesheets and so,
it is not needed to call it 2 times since the rpc will return the exact
same result.

This commit removes the rpc call when we compute the suggestions to only
load the timesheets when we load all the data.

## [FIX] timesheet_grid: show chronological view instead of project view

Before this commit, the `by project` view were loaded first in the
timesheet assistant action, to group the suggestion by project, the
problem is at the beginning the view will not really show a perfect
matching and so the user could think the feature does not work and he
will not understand how to correctly match the suggestions shown in the
view.

This commit changes the view loaded by default in Timesheets Assistant
to first show the chronological view, that view is more logical for the
current user to rethink what he did in the past to correctly map the
events to a project and a task when he generates his timesheets thanks
to those events. The by project view is still useful afterwards when the
system has learned the choices made by the current user.

## [FIX] timesheet_grid: ensure events are consumed forever

Before this commit, the suggestions removed by the current user comes
back when he changes the date and come back to the day he removes the
suggestions. The reason is because a shallow copy of events consumed is
made and that copy alters the duration of the initial object.

This commit avoids copying the consumed events object to make sure the
initial object is not altered when processing the events to remove them
if they are removed before by the user.

### Steps to reproduce the issue:

1. install timesheet_grid and Activity watch, makes sure Activity watch
collects some activities on your computer.
2. Go to Assistant menu in timesheets app.
3. Remove some suggestions displayed in the right panel.
4. Go to next date.
5. Come back to previous date.

### Expected Behavior:


The suggestions removed should not appear again.

### Actual Behavior:

The suggestions removed come back in the view.

## [FIX] timesheet_grid: fix flicker when suggestion selected

Before this commit, when the user selects a suggestion in timesheet
assistant, there is a small flicker appears because the height of the
row grows because of the border added to highlight the suggestion
selected.

This commit reviews a bit the style to make sure the border bottom in
the previous element is removed if the element is not selected or if the
2 consecutives suggestions are selected.

## [FIX] timesheet_grid: fix discord rules to handle discord in web

Before this commit, when the user uses discord in its browser instead of
the app on his computer, the discord rules don't catch the activity
watch events because the tab title is different than the windows name in
the app.

This commit adapts the regex of Discord rules to handle the both use
cases.

task-[6385639](https://www.odoo.com/odoo/project.task/6385639)

Forward-Port-Of: odoo/enterprise#125599
Forward-Port-Of: odoo/enterprise#124855

Steps to Reproduce:
1. Configure Payment Term (Accounting > Configuration > Payment Terms) containing multiple installments.
2. Create a Customer Invoice with this Payment Term.
3. Post the invoice.
4. Register a payment and fully reconcile one of the installments.
5. Navigate to the customer's Follow-Up Report (Accounting > Reporting > Partner Ledger > Report: Follow-Up Report).
6. Navigate to remaining open installment/account move line for that invoice.
7. Turn On or Off the No Follow-Up toggle for the invoice.

An error occurs when enabling or disabling the No Follow-Up toggle.

Issue:
Enabling or disabling the No Follow-Up toggle on a remaining open installment in the Follow-Up Report raises a server error when the invoice contains multiple installments and one or more installments are already fully reconciled.

Root Cause:
The Follow-Up Report only loads and sends non-fully reconciled account move lines from the JavaScript side through all_line_ids. In action_toggle_no_followup(), when the selected line belongs to an invoice, the code retrieves all receivable/payable lines of the invoice, including fully reconciled installments:

```
move.line_ids.filtered(
    lambda line: line.account_type in ('asset_receivable', 'liability_payable'),
)
```

The method then attempts to map every receivable/payable line to a report line ID using aml_id_to_line_id. Since fully reconciled installments are not present in all_line_ids, they are missing from the mapping dictionary, causing a KeyError when accessing:

`aml_id_to_line_id[line.id]
`

Fix:
Restricted the impacted lines to those present in the report by adding a check that the account move line exists in aml_id_to_line_id before performing the mapping:

```
lambda line: line.account_type in ('asset_receivable', 'liability_payable')
             and line.id in aml_id_to_line_id
```


opw-6245448

Forward-Port-Of: odoo/enterprise#126785
Forward-Port-Of: odoo/enterprise#126156

## Behavior Before the PR
When an employee did not have explicit `hours_from` and `hours_to` values defined, their shift was in the **Schedule by X** pivot view but was not included in the **Planning / Timesheets Analysis** report.

## Steps to Reproduce
1. Create an employee with a Flexible Working Schedule in the Employee form, or configure working hours where both `Hour from` and `Hour to` are left unset.
2. Add a shift for this employee linked to a project and a task.
3. Publish the shift.
4. Navigate to **Planning → Schedule → By Project**, switch to the pivot view, and observe that the shift created in step 2 appears and is counted.
5. Navigate to **Planning → Reporting → Planning / Timesheets Analysis**, switch to the pivot view, and observe that the same shift does not appear.

## Behavior After the PR
When an employee does not have explicit `hours_from` and `hours_to` values, their shift is now considered valid in both the **Schedule by X** views and the **Planning / Timesheets Analysis** report.

## Additional Notes
- In earlier versions of Odoo, the `Work From` and `Work To` fields were mandatory. With a change to flexible working schedules and the option to define only the total number of hours per day, these fields may now be left empty. This change exposed the underlying issue addressed by this fix.

task-[5969788](https://www.odoo.com/odoo/project/4105/tasks/5969788)

Forward-Port-Of: odoo/enterprise#110606

## Current behavior:
The user Partner Commissions access rights as All Documents or Own Documents and Purchase access rights as User. With this configuration, the user is unable to create new Purchase Orders, and existing Purchase Orders are also not visible in the Purchase module.

## Expected behavior:
The expected behavior is that the user should be able to create and view Purchase Orders with these access rights. Additionally, clarification is required regarding the purpose of the new Partner Commissions access group.

## Steps to reproduce:
- Go to user and assign Partner Commission rights as All or own document.
- On Purchase, select group as User.

## Cause of the issue:
partner_commission adds commission-specific purchase order record rules, but purchase users have no matching purchase-order rule in that module. For mixed-role users, the commission rule ends up restricting standard purchase orders as well.

## Fix:
Apply the module's explicit all-purchase rule to purchase users so mixed users keep base procurement access while commission-only users remain restricted by the commission rules.

opw-6366074

Forward-Port-Of: odoo/enterprise#126003

mark_urbanpiper_prep_order_as_printed() raised ValueError when the
'urbanpiper_printed' flag was already set, to stop the same order from
printing its preparation ticket twice (https://github.com/odoo/enterprise/pull/103894,
Task-5353283).

Accepting an UrbanPiper order fires this RPC from two places for the
same order: synchronously from TicketScreen, and again via the
DELIVERY_ORDER_COUNT bus notification the accept flow itself
broadcasts. Under load, both requests race for the row lock; Odoo's
retrying() replays the loser on lock contention, and by the time it
replays the winner has already committed, so the loser hits the
already-printed branch and raises. The raise is an unhandled
ValueError, so it surfaces as a 500 and fails any tour that accepts
an order (test_frontend.py, test_order_receipt.py),
intermittently and CI-timing-dependent only.

The only caller (pos_store.js: _sendDeliveryOrderForPreparation)
already wraps the RPC in try/catch and treats a caught exception
exactly like a falsy return value: either way it just skips sending
the ticket to preparation. No other code reads or writes
urbanpiper_printed, and no webhook path calls this method, so
returning False is behaviorally identical for every real caller and
safe to make the default.

This also removes the mark_urbanpiper_prep_order_as_printed_patch
monkeypatch added alongside the original raise in test_01_order_flow:
it existed solely to swallow this exact ValueError for that one tour,
which is no longer needed now that the method itself is idempotent.

runbot error: 941514

Forward-Port-Of: odoo/enterprise#125840

Steps to reproduce:
-------------------------------------------------
1. Install the `sale_project` module
2. Create a test user with Project User rights
3. Create a Project Role with the Created User as a Team Member
4. Create a Template Project as follows:
    * Add one task to the template project
    * Add the created Project role to the Task
5. Create a Service Type Product with:
    * Create on order: Project
    * Project Template: Created Template
6. Archive the Created User
7. Create and Confirm the Sale Order with the Created Product

Observation:
-------------------------------------------------
The generated task is assigned to the archived user, although the archived user is no longer part of the Project Role.

Issue:
-------------------------------------------------
While creating Project and Tasks from template, the context disable active record filtering (e.g., `active_test=False`), causing the assignment logic to fetch both active and inactive/archived users linked to the role. https://github.com/odoo/odoo/blob/8ec646e51497b38d34ea59296e0fc8644a50ee3a/odoo/orm/models.py#L4868

After that, during the `copy_data` method, It takes all the users from the roles without checking weather user is active or not
https://github.com/odoo/odoo/blob/8ec646e51497b38d34ea59296e0fc8644a50ee3a/addons/project/models/project_task.py#L890-L904

And even if we pass only Active users from this method, on moving further, it reassigns the users from roles without checking the Active field of the user

https://github.com/odoo/enterprise/blob/5abb147f9bf725daafc202d8259a5bb8a9b78d94/project_enterprise/models/project_task.py#L501-L503

https://github.com/odoo/enterprise/blob/5abb147f9bf725daafc202d8259a5bb8a9b78d94/project_enterprise/models/project_task.py#L544-L553

Due to this, the Archived User is also assigned to the tasks from the project roles

Solution:
-------------------------------------------------
Apply a `filtered('active')` check directly on the project role's users `(role.user_ids)` within the core task-copying logic in both `project` and `project_enterprise` modules. This ensures archived users are universally excluded from task assignments during template copying, regardless of what triggers the template instantiation.

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

opw-6350841

Forward-Port-Of: odoo/enterprise#125637

`user_domain` (in the context) is supposed to contain the domain defined
by the user (in the search bar). It was not the case for all gantt
views, and produced inconsistent results, as that domain is used to know
when to display the employees without leaves/attendances.

The PR fixes that issue by creating the `HrGanttModel` class, that takes
care of defining the `user_domain` correctly.

This class also disables the *Group By* menu, and defaults to grouping
by employees. This was decided for the following reasons:
- All gantt views inheriting this class would group by employee
- Grouping by other fields would already not work in some cases
- It's very difficult to add employees without records if the gantt is
grouped by multiple fields at once

Affected `_get_gantt_data()` functions have been adapted accordingly

The access models (the ones defined in the `access.csv` files) are
implied, and thus never passed as a parameter to `get_gantt_data()`, so
we need to also manually add them when converting the model to the
related field used in `groupby`

task-5502544

Steps to Reproduce:
1. Configure Payment Term (Accounting > Configuration > Payment Terms) containing multiple installments.
2. Create a Customer Invoice with this Payment Term.
3. Post the invoice.
4. Register a payment and fully reconcile one of the installments.
5. Navigate to the customer's Follow-Up Report (Accounting > Reporting > Partner Ledger > Report: Follow-Up Report).
6. Navigate to remaining open installment/account move line for that invoice.
7. Turn On or Off the No Follow-Up toggle for the invoice.

An error occurs when enabling or disabling the No Follow-Up toggle.

Issue:
Enabling or disabling the No Follow-Up toggle on a remaining open installment in the Follow-Up Report raises a server error when the invoice contains multiple installments and one or more installments are already fully reconciled.

Root Cause:
The Follow-Up Report only loads and sends non-fully reconciled account move lines from the JavaScript side through all_line_ids. In action_toggle_no_followup(), when the selected line belongs to an invoice, the code retrieves all receivable/payable lines of the invoice, including fully reconciled installments:

```
move.line_ids.filtered(
    lambda line: line.account_type in ('asset_receivable', 'liability_payable'),
)
```

The method then attempts to map every receivable/payable line to a report line ID using aml_id_to_line_id. Since fully reconciled installments are not present in all_line_ids, they are missing from the mapping dictionary, causing a KeyError when accessing:

`aml_id_to_line_id[line.id]
`

Fix:
Restricted the impacted lines to those present in the report by adding a check that the account move line exists in aml_id_to_line_id before performing the mapping:

```
lambda line: line.account_type in ('asset_receivable', 'liability_payable')
             and line.id in aml_id_to_line_id
```


opw-6245448

Forward-Port-Of: odoo/enterprise#126785
Forward-Port-Of: odoo/enterprise#126156

Issue:
The default Employee grouped Attendance Gantt hides an attendance when its employee has no contract. The record remains accessible from the list view or after removing the default grouping.

Steps to reproduce:
- Create an attendance-based employee without a contract.
- Create an attendance for the employee.
- Open Attendances with the default Date and Employee groupings.

Cause:
In https://github.com/odoo/enterprise/blob/c8c91758b148cced1b7b5c59479fba7aaea033c1/hr_attendance_gantt/models/hr_attendance.py#L151-L164 

`_get_gantt_data_group_by_employee()` builds `employees_on_page` using only employees whose versions overlap the displayed period. It then adds those employee IDs to `attendances_domain`. A contractless employee is therefore excluded before its otherwise valid attendance is fetched.

Solution:
Build the employee visibility domain from employees having either an overlapping contract or an attendance matching the effective Gantt domain. Apply the same domain to the employee query and group count so contractless employees with visible attendances are included while contractless employees without attendances remain hidden.

opw-6416111

## Behavior Before the PR
When an employee did not have explicit `hours_from` and `hours_to` values defined, their shift was in the **Schedule by X** pivot view but was not included in the **Planning / Timesheets Analysis** report.

## Steps to Reproduce
1. Create an employee with a Flexible Working Schedule in the Employee form, or configure working hours where both `Hour from` and `Hour to` are left unset.
2. Add a shift for this employee linked to a project and a task.
3. Publish the shift.
4. Navigate to **Planning → Schedule → By Project**, switch to the pivot view, and observe that the shift created in step 2 appears and is counted.
5. Navigate to **Planning → Reporting → Planning / Timesheets Analysis**, switch to the pivot view, and observe that the same shift does not appear.

## Behavior After the PR
When an employee does not have explicit `hours_from` and `hours_to` values, their shift is now considered valid in both the **Schedule by X** views and the **Planning / Timesheets Analysis** report.

## Additional Notes
- In earlier versions of Odoo, the `Work From` and `Work To` fields were mandatory. With a change to flexible working schedules and the option to define only the total number of hours per day, these fields may now be left empty. This change exposed the underlying issue addressed by this fix.

task-[5969788](https://www.odoo.com/odoo/project/4105/tasks/5969788)

Forward-Port-Of: odoo/enterprise#110606

Steps to reproduce:
-------------------------------------------------
1. Install the `sale_project` module
2. Create a test user with Project User rights
3. Create a Project Role with the Created User as a Team Member
4. Create a Template Project as follows:
    * Add one task to the template project
    * Add the created Project role to the Task
5. Create a Service Type Product with:
    * Create on order: Project
    * Project Template: Created Template
6. Archive the Created User
7. Create and Confirm the Sale Order with the Created Product

Observation:
-------------------------------------------------
The generated task is assigned to the archived user, although the archived user is no longer part of the Project Role.

Issue:
-------------------------------------------------
While creating Project and Tasks from template, the context disable active record filtering (e.g., `active_test=False`), causing the assignment logic to fetch both active and inactive/archived users linked to the role. https://github.com/odoo/odoo/blob/8ec646e51497b38d34ea59296e0fc8644a50ee3a/odoo/orm/models.py#L4868

After that, during the `copy_data` method, It takes all the users from the roles without checking weather user is active or not
https://github.com/odoo/odoo/blob/8ec646e51497b38d34ea59296e0fc8644a50ee3a/addons/project/models/project_task.py#L890-L904

And even if we pass only Active users from this method, on moving further, it reassigns the users from roles without checking the Active field of the user

https://github.com/odoo/enterprise/blob/5abb147f9bf725daafc202d8259a5bb8a9b78d94/project_enterprise/models/project_task.py#L501-L503

https://github.com/odoo/enterprise/blob/5abb147f9bf725daafc202d8259a5bb8a9b78d94/project_enterprise/models/project_task.py#L544-L553

Due to this, the Archived User is also assigned to the tasks from the project roles

Solution:
-------------------------------------------------
Apply a `filtered('active')` check directly on the project role's users `(role.user_ids)` within the core task-copying logic in both `project` and `project_enterprise` modules. This ensures archived users are universally excluded from task assignments during template copying, regardless of what triggers the template instantiation.

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

opw-6350841

Forward-Port-Of: odoo/enterprise#125637

mark_urbanpiper_prep_order_as_printed() raised ValueError when the
'urbanpiper_printed' flag was already set, to stop the same order from
printing its preparation ticket twice (https://github.com/odoo/enterprise/pull/103894,
Task-5353283).

Accepting an UrbanPiper order fires this RPC from two places for the
same order: synchronously from TicketScreen, and again via the
DELIVERY_ORDER_COUNT bus notification the accept flow itself
broadcasts. Under load, both requests race for the row lock; Odoo's
retrying() replays the loser on lock contention, and by the time it
replays the winner has already committed, so the loser hits the
already-printed branch and raises. The raise is an unhandled
ValueError, so it surfaces as a 500 and fails any tour that accepts
an order (test_frontend.py, test_order_receipt.py),
intermittently and CI-timing-dependent only.

The only caller (pos_store.js: _sendDeliveryOrderForPreparation)
already wraps the RPC in try/catch and treats a caught exception
exactly like a falsy return value: either way it just skips sending
the ticket to preparation. No other code reads or writes
urbanpiper_printed, and no webhook path calls this method, so
returning False is behaviorally identical for every real caller and
safe to make the default.

This also removes the mark_urbanpiper_prep_order_as_printed_patch
monkeypatch added alongside the original raise in test_01_order_flow:
it existed solely to swallow this exact ValueError for that one tour,
which is no longer needed now that the method itself is idempotent.

runbot error: 941514

Forward-Port-Of: odoo/enterprise#125840

mark_urbanpiper_prep_order_as_printed() raised ValueError when the
'urbanpiper_printed' flag was already set, to stop the same order from
printing its preparation ticket twice (https://github.com/odoo/enterprise/pull/103894,
Task-5353283).

Accepting an UrbanPiper order fires this RPC from two places for the
same order: synchronously from TicketScreen, and again via the
DELIVERY_ORDER_COUNT bus notification the accept flow itself
broadcasts. Under load, both requests race for the row lock; Odoo's
retrying() replays the loser on lock contention, and by the time it
replays the winner has already committed, so the loser hits the
already-printed branch and raises. The raise is an unhandled
ValueError, so it surfaces as a 500 and fails any tour that accepts
an order (test_frontend.py, test_order_receipt.py),
intermittently and CI-timing-dependent only.

The only caller (pos_store.js: _sendDeliveryOrderForPreparation)
already wraps the RPC in try/catch and treats a caught exception
exactly like a falsy return value: either way it just skips sending
the ticket to preparation. No other code reads or writes
urbanpiper_printed, and no webhook path calls this method, so
returning False is behaviorally identical for every real caller and
safe to make the default.

This also removes the mark_urbanpiper_prep_order_as_printed_patch
monkeypatch added alongside the original raise in test_01_order_flow:
it existed solely to swallow this exact ValueError for that one tour,
which is no longer needed now that the method itself is idempotent.

runbot error: 941514

Forward-Port-Of: odoo/enterprise#125840

Steps to Reproduce:
1. Configure Payment Term (Accounting > Configuration > Payment Terms) containing multiple installments.
2. Create a Customer Invoice with this Payment Term.
3. Post the invoice.
4. Register a payment and fully reconcile one of the installments.
5. Navigate to the customer's Follow-Up Report (Accounting > Reporting > Partner Ledger > Report: Follow-Up Report).
6. Navigate to remaining open installment/account move line for that invoice.
7. Turn On or Off the No Follow-Up toggle for the invoice.

An error occurs when enabling or disabling the No Follow-Up toggle.

Issue:
Enabling or disabling the No Follow-Up toggle on a remaining open installment in the Follow-Up Report raises a server error when the invoice contains multiple installments and one or more installments are already fully reconciled.

Root Cause:
The Follow-Up Report only loads and sends non-fully reconciled account move lines from the JavaScript side through all_line_ids. In action_toggle_no_followup(), when the selected line belongs to an invoice, the code retrieves all receivable/payable lines of the invoice, including fully reconciled installments:

```
move.line_ids.filtered(
    lambda line: line.account_type in ('asset_receivable', 'liability_payable'),
)
```

The method then attempts to map every receivable/payable line to a report line ID using aml_id_to_line_id. Since fully reconciled installments are not present in all_line_ids, they are missing from the mapping dictionary, causing a KeyError when accessing:

`aml_id_to_line_id[line.id]
`

Fix:
Restricted the impacted lines to those present in the report by adding a check that the account move line exists in aml_id_to_line_id before performing the mapping:

```
lambda line: line.account_type in ('asset_receivable', 'liability_payable')
             and line.id in aml_id_to_line_id
```


opw-6245448

Forward-Port-Of: odoo/enterprise#126785
Forward-Port-Of: odoo/enterprise#126156

**Issue**
When rental transfers are enabled and rental pickups/returns are processed through stock pickings, it may become impossible to perform a subsequent rental return through the rental return wizard.

**Steps to reproduce**
- Activate "Rental Transfers" in the settings
- Create a rental product P, tracked by serial number
- Create two serial numbers for P
- Create and confirm a rental order for 2 units of P
- Validate the pickup transfer
- Partially validate the return transfer without creating a backorder
- Open the rental order and click on "Return" 
-> The return wizard opens without any available serial number and validation fails with a serial number-related error.

**Cause**
When clicking on "Return", if there is no pending pickup/return transfer: https://github.com/odoo/enterprise/blob/d1ba2417affb81c4351ab9f86bc0a6ad5ceb8caf/sale_stock_renting/models/sale_order.py#L62-L68 the rental return wizard is opened directly:
https://github.com/odoo/enterprise/blob/d1ba2417affb81c4351ab9f86bc0a6ad5ceb8caf/sale_renting/models/sale_order.py#L316 No serial number is prefilled in the wizard because `returned_lot_ids` is empty: https://github.com/odoo/enterprise/blob/d1ba2417affb81c4351ab9f86bc0a6ad5ceb8caf/sale_stock_renting/wizard/rental_processing.py#L122-L124 This is because `returnable_lot_ids` is empty as well. `returnable_lot_ids` is computed while generating the wizard lines: https://github.com/odoo/enterprise/blob/d1ba2417affb81c4351ab9f86bc0a6ad5ceb8caf/sale_renting/wizard/rental_processing.py#L38 https://github.com/odoo/enterprise/blob/d1ba2417affb81c4351ab9f86bc0a6ad5ceb8caf/sale_renting/wizard/rental_processing.py#L47-L48 https://github.com/odoo/enterprise/blob/d1ba2417affb81c4351ab9f86bc0a6ad5ceb8caf/sale_stock_renting/wizard/rental_processing.py#L99-L106 and `returnable_lots` is empty because both `pickedup_lots` and `returned_lots` are. Those fields are currently only populated through the rental wizard flow: https://github.com/odoo/enterprise/blob/d1ba2417affb81c4351ab9f86bc0a6ad5ceb8caf/sale_stock_renting/wizard/rental_processing.py#L42-L43 https://github.com/odoo/enterprise/blob/d1ba2417affb81c4351ab9f86bc0a6ad5ceb8caf/sale_stock_renting/wizard/rental_processing.py#L160-L161 https://github.com/odoo/enterprise/blob/d1ba2417affb81c4351ab9f86bc0a6ad5ceb8caf/sale_stock_renting/wizard/rental_processing.py#L166-L167

Since this flow uses stock pickings instead of the rental wizard, those fields are never updated, preventing the wizard from determining any returnable serial number.

opw-6150305

Forward-Port-Of: odoo/enterprise#119257

mark_urbanpiper_prep_order_as_printed() raised ValueError when the
'urbanpiper_printed' flag was already set, to stop the same order from
printing its preparation ticket twice (https://github.com/odoo/enterprise/pull/103894,
Task-5353283).

Accepting an UrbanPiper order fires this RPC from two places for the
same order: synchronously from TicketScreen, and again via the
DELIVERY_ORDER_COUNT bus notification the accept flow itself
broadcasts. Under load, both requests race for the row lock; Odoo's
retrying() replays the loser on lock contention, and by the time it
replays the winner has already committed, so the loser hits the
already-printed branch and raises. The raise is an unhandled
ValueError, so it surfaces as a 500 and fails any tour that accepts
an order (test_frontend.py, test_order_receipt.py),
intermittently and CI-timing-dependent only.

The only caller (pos_store.js: _sendDeliveryOrderForPreparation)
already wraps the RPC in try/catch and treats a caught exception
exactly like a falsy return value: either way it just skips sending
the ticket to preparation. No other code reads or writes
urbanpiper_printed, and no webhook path calls this method, so
returning False is behaviorally identical for every real caller and
safe to make the default.

This also removes the mark_urbanpiper_prep_order_as_printed_patch
monkeypatch added alongside the original raise in test_01_order_flow:
it existed solely to swallow this exact ValueError for that one tour,
which is no longer needed now that the method itself is idempotent.

runbot error: 941514

Forward-Port-Of: odoo/enterprise#125840

Since `company_id` on `worksheet.template` changed due to this a973d7d from a Many2many to a Many2one field.

For example, in v17, a single worksheet template linked to 3 companies via the m2m field was returned as 1 record when opening Design Template. After the upgrade in v18, company_id became m2o, and the same data is split into 3 separate records (one per company).

When trying to add a customization via Studio, the search [fetches](https://github.com/odoo/enterprise/blob/18.0/worksheet/controllers/main.py#L12) records based on the model set on the worksheet. In the new version, Studio
[creates](https://github.com/odoo/enterprise/blob/18.0/worksheet/models/worksheet_template.py#L112)
 a new model, but for existing records the
model is the same across the 3 worksheet records tied to the same template. This causes the search to match all 3 records and raise a SingletonError.

```py
Traceback (most recent call last):
  File "/home/odoo/src/odoo/19.0/odoo/http.py", line 2856, in __call__
    response = request._serve_db()
  File "/home/odoo/src/odoo/19.0/odoo/http.py", line 2331, in _serve_db
    raise self._update_served_exception(exc)
  File "/home/odoo/src/odoo/19.0/odoo/http.py", line 2329, in _serve_db
    return service_model.retrying(serve_func, env=self.env)
  File "/home/odoo/src/odoo/19.0/odoo/service/model.py", line 188, in retrying
    result = func()
  File "/home/odoo/src/odoo/19.0/odoo/http.py", line 2384, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "/home/odoo/src/odoo/19.0/odoo/http.py", line 2599, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "/home/odoo/src/odoo/19.0/odoo/addons/base/models/ir_http.py", line 353, in _dispatch
    result = endpoint(**request.params)
  File "/home/odoo/src/odoo/19.0/odoo/http.py", line 838, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "/home/odoo/src/enterprise/19.0/industry_fsm_report/controllers/main.py", line 9, in edit_view
    action = super().edit_view(view_id, studio_view_arch, operations, model, context)
  File "/home/odoo/src/odoo/19.0/odoo/http.py", line 838, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "/home/odoo/src/enterprise/19.0/worksheet/controllers/main.py", line 17, in edit_view
    worksheet_template_to_change._generate_qweb_report_template()
  File "/home/odoo/src/enterprise/19.0/worksheet/models/worksheet_template.py", line 490, in _generate_qweb_report_template
    new_arch = self._get_qweb_arch(worksheet_template.model_id, report_name, form_view_id)
  File "/home/odoo/src/enterprise/19.0/worksheet/models/worksheet_template.py", line 460, in _get_qweb_arch
    if 'name' in row_node.attrib and row_node.attrib['name'] not in self._get_qweb_arch_omitted_fields() and row_node.attrib['name'] in form_view_fields:
  File "/home/odoo/src/enterprise/19.0/worksheet/models/worksheet_template.py", line 378, in _get_qweb_arch_omitted_fields
    'x_%s_id' % self.res_model.replace('.', '_'), 'x_name',  # redundant
  File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1657, in __get__
    record.ensure_one()
  File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 5942, in ensure_one
    raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: worksheet.template(3, 14, 18)
```

OPW: 6389190

Forward-Port-Of: odoo/enterprise#126773

Steps to Reproduce:
1. Configure Payment Term (Accounting > Configuration > Payment Terms) containing multiple installments.
2. Create a Customer Invoice with this Payment Term.
3. Post the invoice.
4. Register a payment and fully reconcile one of the installments.
5. Navigate to the customer's Follow-Up Report (Accounting > Reporting > Partner Ledger > Report: Follow-Up Report).
6. Navigate to remaining open installment/account move line for that invoice.
7. Turn On or Off the No Follow-Up toggle for the invoice.

An error occurs when enabling or disabling the No Follow-Up toggle.

Issue:
Enabling or disabling the No Follow-Up toggle on a remaining open installment in the Follow-Up Report raises a server error when the invoice contains multiple installments and one or more installments are already fully reconciled.

Root Cause:
The Follow-Up Report only loads and sends non-fully reconciled account move lines from the JavaScript side through all_line_ids. In action_toggle_no_followup(), when the selected line belongs to an invoice, the code retrieves all receivable/payable lines of the invoice, including fully reconciled installments:

```
move.line_ids.filtered(
    lambda line: line.account_type in ('asset_receivable', 'liability_payable'),
)
```

The method then attempts to map every receivable/payable line to a report line ID using aml_id_to_line_id. Since fully reconciled installments are not present in all_line_ids, they are missing from the mapping dictionary, causing a KeyError when accessing:

`aml_id_to_line_id[line.id]
`

Fix:
Restricted the impacted lines to those present in the report by adding a check that the account move line exists in aml_id_to_line_id before performing the mapping:

```
lambda line: line.account_type in ('asset_receivable', 'liability_payable')
             and line.id in aml_id_to_line_id
```


opw-6245448

Forward-Port-Of: odoo/enterprise#126156

Since `company_id` on `worksheet.template` changed due to this a973d7d from a Many2many to a Many2one field.

For example, in v17, a single worksheet template linked to 3 companies via the m2m field was returned as 1 record when opening Design Template. After the upgrade in v18, company_id became m2o, and the same data is split into 3 separate records (one per company).

When trying to add a customization via Studio, the search [fetches](https://github.com/odoo/enterprise/blob/18.0/worksheet/controllers/main.py#L12) records based on the model set on the worksheet. In the new version, Studio
[creates](https://github.com/odoo/enterprise/blob/18.0/worksheet/models/worksheet_template.py#L112)
 a new model, but for existing records the
model is the same across the 3 worksheet records tied to the same template. This causes the search to match all 3 records and raise a SingletonError.

```py
Traceback (most recent call last):
  File "/home/odoo/src/odoo/19.0/odoo/http.py", line 2856, in __call__
    response = request._serve_db()
  File "/home/odoo/src/odoo/19.0/odoo/http.py", line 2331, in _serve_db
    raise self._update_served_exception(exc)
  File "/home/odoo/src/odoo/19.0/odoo/http.py", line 2329, in _serve_db
    return service_model.retrying(serve_func, env=self.env)
  File "/home/odoo/src/odoo/19.0/odoo/service/model.py", line 188, in retrying
    result = func()
  File "/home/odoo/src/odoo/19.0/odoo/http.py", line 2384, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "/home/odoo/src/odoo/19.0/odoo/http.py", line 2599, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "/home/odoo/src/odoo/19.0/odoo/addons/base/models/ir_http.py", line 353, in _dispatch
    result = endpoint(**request.params)
  File "/home/odoo/src/odoo/19.0/odoo/http.py", line 838, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "/home/odoo/src/enterprise/19.0/industry_fsm_report/controllers/main.py", line 9, in edit_view
    action = super().edit_view(view_id, studio_view_arch, operations, model, context)
  File "/home/odoo/src/odoo/19.0/odoo/http.py", line 838, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "/home/odoo/src/enterprise/19.0/worksheet/controllers/main.py", line 17, in edit_view
    worksheet_template_to_change._generate_qweb_report_template()
  File "/home/odoo/src/enterprise/19.0/worksheet/models/worksheet_template.py", line 490, in _generate_qweb_report_template
    new_arch = self._get_qweb_arch(worksheet_template.model_id, report_name, form_view_id)
  File "/home/odoo/src/enterprise/19.0/worksheet/models/worksheet_template.py", line 460, in _get_qweb_arch
    if 'name' in row_node.attrib and row_node.attrib['name'] not in self._get_qweb_arch_omitted_fields() and row_node.attrib['name'] in form_view_fields:
  File "/home/odoo/src/enterprise/19.0/worksheet/models/worksheet_template.py", line 378, in _get_qweb_arch_omitted_fields
    'x_%s_id' % self.res_model.replace('.', '_'), 'x_name',  # redundant
  File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1657, in __get__
    record.ensure_one()
  File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 5942, in ensure_one
    raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: worksheet.template(3, 14, 18)
```

OPW: 6389190

Forward-Port-Of: odoo/enterprise#126773

Steps to reproduce:
-------------------
1. Install `l10n_mx_edi_pos` and set the company to Mexico.
2. In PoS, make an order with one product and pay it.
3. Open the order in the backend, click "Return Products" to make a refund, but don't pay it, cancel it instead.
4. From the same order, click "Return Products" again to make a second refund, and pay it normally.
5. Go to the orders list, select the main order and the paid refund (not the cancelled one), then Actions > Create Global Invoice.

-> Observation: error in the global invoice.

In the CFDI tab of the main order the line is "Send Global In Error", and hovering on it the detail says "Failed to distribute some negative lines".

Why:
----
When we make the global invoice, we remove the refunds from the order. A cancelled refund was never paid, so we should not count it. But we were counting it too. So we removed the refund amount twice in our case, one for the paid refund, and one for the cancelled one, and we end up with an order with negative amount that cannot be distributed.

The fix:
--------
We now skip the cancelled orders when we search the refunds, the same way it is done above when we collect the refunded orders.

opw-6261404

Forward-Port-Of: odoo/enterprise#120996

The `unpaid_structure_ids` field was removed from work entry types to simplify the configuration. Previously, a work entry type could be marked as unpaid either by adding payroll structures to `unpaid_structure_ids` or by setting `amount_rate` to 0. From now on, `amount_rate = 0` is the single source of truth for unpaid work entries.

As part of this change:

* Set `amount_rate` to 0 for out of contract entries, unpaid leaves, and all work entry types that were previously unpaid in monthly structures across localizations.
* Kept `l10n_be_work_entry_type_notice` with `amount_rate = 1`. Although it was marked as unpaid for the 13th month structure, it remains paid in the monthly structure. Since work day lines are not used in the 13th month computation, keeping its rate would have no functional impact on the 13th month payroll calculation.
* Removed unpaid work entry types from the Belgian `REMUNERATION_BASE`, `ONSS_BASE`, and `WITHHOLDING_BASE` categories, as they now have `amount_rate = 0` and therefore no impact on these bases.
* Removed Egyptian salary rules that deducted unpaid leaves and out of contract periods. Since these work entries now contribute 0 to the base salary, keeping the deduction rules would result in double deductions.

---
Introduce the `EXTRA_HOURS` category on work entry types as the source of truth for identifying extra hours.

The `is_extra_hours` field is moved from `hr_work_entry` to `hr_payroll` and turned into a stored computed field based on the work entry type categories. This preserves its usage in payroll computations while making the category the source of truth.

Task: 6292486

## **Steps to reproduce:**

1. Create a Service product with Create on Order set to Task and Project set to Field service project.
2. Create a Sales Order containing a storable product and a service product.
3. Confirm the Sales Order to generate the project, task, and delivery order.
4. Validate the delivery order.
5. Create and validate a return for the delivery.
6. Create a return of the return to deliver the products again, but do not validate this new delivery.
7. Open the related task and click on Mark as Done button.

## **Issue:**

In a delivery -> return -> return of return workflow, the stock move goes into this code
https://github.com/odoo/enterprise/blob/59b86f106862c3a364ba633a1580d9051f2fe7ca/industry_fsm_stock/models/project_task.py#L89-L90 the traversal repeatedly revisits the same stock moves through move_dest_ids, causing the loop to alternate between the same move recordsets indefinitely. As a result, the loop never terminates, eventually exhausting the memory and raising a `MemoryError`.

## **Solution:**

Track the stock moves that have already been visited and continue the traversal only with unseen destination moves.

Runbot Video : [Video](https://drive.google.com/file/d/1wiqggjx8T-Mtl4T1JgCsfwBbgQU18nYF/view?usp=drive_link)

OPW - 6420961

Forward-Port-Of: odoo/enterprise#125962

When opening reports with `default_opening_date_filter='this_year'`(e.g., P&L, Partner Ledger), the date filter dropdown showed incorrect defaults for non-selected period types:
- Month showed the last month of the fiscal year (e.g., December)
  instead of the current month
- Quarter showed Q4 instead of the current quarter

This happened because `initDateFilterState()` used the backend's `date_to` (fiscal year end) as the reference for computing all filter periods. For `this_year`, `date_to` is the year-end date (e.g., 2026-12-31), so `computePeriodRange()` for month/quarter returned periods containing that date rather than today's date. Reports with `this_month` or `today` defaults were unaffected because their `date_to` is naturally close to today.

Now, non-selected filters use today as their reference date on initial load whenever today falls within the report period, while the selected filter continues to use the backend's `date_to`, preserving the alignment behavior introduced in the date filter refactor (https://github.com/odoo/enterprise/commit/40484f985f511edd7ba2ae759ce63ef564bcf1f7).

Additionally, selecting the custom comparison filter now triggers an immediate reload so its default date range is recomputed by the backend. The custom comparison range is initialized using the current fiscal year up to today, capping its end date to today instead of inheriting the report's `date_to`, which could otherwise default to a future date for yearly reports.

task-6229588

Forward-Port-Of: odoo/enterprise#127316
Forward-Port-Of: odoo/enterprise#121638

Bug :
	- create an unvalidated leave
	- on the payrun Time view, when validating the view -> click on continue -> error popup appears says you have unvalidated leave (BUG 1)
	- on the payrun Payslips view, when canceling a payslip , the KPIs values don't change unless you refresh (BUG 2)

Reason :
	- PayRunMixin now subscribes to its model's "update" bus event and forwards it to updatePayRun, so any pay run view whose model emits "update" keeps the summary in sync.

	- The natural trigger is the model's "update" bus event, but the mixin never listened to it. On top of that the relational payslip list never even emits "update" on a programmatic reload: model.load() (cog actions) and root.load() (form close, view-button reloads) rebuild the reactive root without calling notify(), which only fires on search/pager changes. The Time view gantt already worked around this because GanttModel.fetchData() calls notify() itself. 

Fix :
	- Subscribe payroll mixing to the "update" notif that will come from the underlaying models.
	- override the onRootLoad hook in payslipListCOntroller to call notify() which sends an "update" message when loading the data.(added a guarderail: only call the notify on the model if it's mounted)

task - 6387933

Forward-Port-Of: odoo/enterprise#125194

Every gantt that needed to display employees without records (without
leaves, attendances, etc.) would implement their own
`_get_gantt_data_group_by_employee()` function. They all do the exact
same thing.

This PR creates the reusable function
`_get_gantt_data_with_empty()`, so that all the
`_get_gantt_data()` functions can reuse that one. That function will
guess the relation model from the `groupby` variable.

`user_domain` (in the context) is supposed to contain the domain defined
by the user (in the search bar). It was not the case for all gantt
views, and produced inconsistent results, as that domain is used to know
when to display the employees without leaves/attendances.

The PR fixes that issue by creating the `HrGanttModel` class, that takes
care of defining the `user_domain` correctly.

This class also disables the *Group By* menu, and defaults to grouping
by employees. This was decided for the following reasons:
- All gantt views inheriting this class would group by employee
- Grouping by other fields would already not work in some cases
- It's very difficult to add employees without records if the gantt is
grouped by multiple fields at once

task-5502544

Steps to reproduce
---
1. Configure a `delivery_easypost` shipping method using the DHL Express carrier.
2. On an international delivery, use Put in Pack to create two or more packages.
3. Validate the delivery.

Issue
---
Validation is blocked with `DHLExpress: rate_error -- DHLExpress multi-shipment rate includes this shipment.`

For an EasyPost multi-shipment order, DHL Express returns the aggregate rate on the first (master) shipment only and adds an informational `rate_error` on the order stating that this rate already covers the whole order, so the remaining shipments carry no rate of their own. The message is not a real error, but `send_shipping` raises on any carrier message whose type is not exempt: https://github.com/odoo/enterprise/blob/534b42def8ae5dc884da4398377f828c49557d6e/delivery_easypost/models/easypost_request.py#L359-L364

`_post_process_ship_response` already detects and clears exactly this harmless message, but only for a hardcoded carrier allowlist introduced in a2de5bc5a14 (`Purolator`, `DPD UK`, `UPS`) that was never extended to DHL Express, so for DHL Express the message survives, reaches the raise, and aborts an otherwise valid shipment: https://github.com/odoo/enterprise/blob/a2de5bc5a14f99b8674c3ee234e4d221b406da0f/delivery_easypost/models/easypost_request.py#L416-L434

`DHL Express` is added to that allowlist so the harmless multi-shipment `rate_error` is posted on the picking and cleared instead of raised. The guard still requires a single `rate_error` carrying the "multi-shipment rate includes this shipment." text with the rate present only on the master shipment, so genuine DHL Express errors keep blocking validation.

opw-6450365

Forward-Port-Of: odoo/enterprise#127164

Steps to reproduce:
- Post a Peruvian invoice so it is sent to SUNAT (directly or through Estela/Digiflow).
- SUNAT's sendBill call hangs and Odoo's request times out (ReadTimeout / ConnectionError), even though SUNAT actually finishes registering the document on its side a moment later.
- Odoo retries sending the same invoice (either automatically through the EDI cron, or manually). SUNAT now replies with a "document already exists" SOAP fault (code 1033/4000), since it processed the previous attempt.
- Odoo tries to recover from this by fetching the CDR through getStatusCdr, but SUNAT has not finished generating it yet, so the lookup also fails.

Cause of the issue:
_l10n_pe_edi_post_invoice_web_service() already has recovery logic for error codes 1033/4000: it calls _l10n_pe_edi_retrieve_cdr() to fetch the CDR and treat the invoice as sent. But when that lookup itself fails (CDR not generated yet), the resulting error keeps the 'blocking_level' set to 'error' from the original SOAP fault. Documents with blocking_level 'error' are excluded from the automatic EDI cron retries (see account.edi.document._cron_process_documents_web_services), so the invoice gets stuck needing a manual retry, which can lose the same race against SUNAT again and again.

Solution:
When the CDR can't be retrieved yet after a 1033/4000 duplicate error, mark the result as 'blocking_level': 'warning' instead of leaving it at 'error'. This keeps the invoice eligible for the automatic EDI cron retries, so Odoo keeps polling SUNAT until the CDR becomes available, instead of requiring manual intervention every time this race is lost.

opw-6393231

mark_urbanpiper_prep_order_as_printed() raised ValueError when the
'urbanpiper_printed' flag was already set, to stop the same order from
printing its preparation ticket twice (https://github.com/odoo/enterprise/pull/103894,
Task-5353283).

Accepting an UrbanPiper order fires this RPC from two places for the
same order: synchronously from TicketScreen, and again via the
DELIVERY_ORDER_COUNT bus notification the accept flow itself
broadcasts. Under load, both requests race for the row lock; Odoo's
retrying() replays the loser on lock contention, and by the time it
replays the winner has already committed, so the loser hits the
already-printed branch and raises. The raise is an unhandled
ValueError, so it surfaces as a 500 and fails any tour that accepts
an order (test_frontend.py, test_order_receipt.py),
intermittently and CI-timing-dependent only.

The only caller (pos_store.js: _sendDeliveryOrderForPreparation)
already wraps the RPC in try/catch and treats a caught exception
exactly like a falsy return value: either way it just skips sending
the ticket to preparation. No other code reads or writes
urbanpiper_printed, and no webhook path calls this method, so
returning False is behaviorally identical for every real caller and
safe to make the default.

This also removes the mark_urbanpiper_prep_order_as_printed_patch
monkeypatch added alongside the original raise in test_01_order_flow:
it existed solely to swallow this exact ValueError for that one tour,
which is no longer needed now that the method itself is idempotent.

runbot error: 941514

Forward-Port-Of: odoo/enterprise#125840

Since `company_id` on `worksheet.template` changed due to this a973d7d from a Many2many to a Many2one field.

For example, in v17, a single worksheet template linked to 3 companies via the m2m field was returned as 1 record when opening Design Template. After the upgrade in v18, company_id became m2o, and the same data is split into 3 separate records (one per company).

When trying to add a customization via Studio, the search [fetches](https://github.com/odoo/enterprise/blob/18.0/worksheet/controllers/main.py#L12) records based on the model set on the worksheet. In the new version, Studio
[creates](https://github.com/odoo/enterprise/blob/18.0/worksheet/models/worksheet_template.py#L112)
 a new model, but for existing records the
model is the same across the 3 worksheet records tied to the same template. This causes the search to match all 3 records and raise a SingletonError.

```py
Traceback (most recent call last):
  File "/home/odoo/src/odoo/19.0/odoo/http.py", line 2856, in __call__
    response = request._serve_db()
  File "/home/odoo/src/odoo/19.0/odoo/http.py", line 2331, in _serve_db
    raise self._update_served_exception(exc)
  File "/home/odoo/src/odoo/19.0/odoo/http.py", line 2329, in _serve_db
    return service_model.retrying(serve_func, env=self.env)
  File "/home/odoo/src/odoo/19.0/odoo/service/model.py", line 188, in retrying
    result = func()
  File "/home/odoo/src/odoo/19.0/odoo/http.py", line 2384, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "/home/odoo/src/odoo/19.0/odoo/http.py", line 2599, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "/home/odoo/src/odoo/19.0/odoo/addons/base/models/ir_http.py", line 353, in _dispatch
    result = endpoint(**request.params)
  File "/home/odoo/src/odoo/19.0/odoo/http.py", line 838, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "/home/odoo/src/enterprise/19.0/industry_fsm_report/controllers/main.py", line 9, in edit_view
    action = super().edit_view(view_id, studio_view_arch, operations, model, context)
  File "/home/odoo/src/odoo/19.0/odoo/http.py", line 838, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "/home/odoo/src/enterprise/19.0/worksheet/controllers/main.py", line 17, in edit_view
    worksheet_template_to_change._generate_qweb_report_template()
  File "/home/odoo/src/enterprise/19.0/worksheet/models/worksheet_template.py", line 490, in _generate_qweb_report_template
    new_arch = self._get_qweb_arch(worksheet_template.model_id, report_name, form_view_id)
  File "/home/odoo/src/enterprise/19.0/worksheet/models/worksheet_template.py", line 460, in _get_qweb_arch
    if 'name' in row_node.attrib and row_node.attrib['name'] not in self._get_qweb_arch_omitted_fields() and row_node.attrib['name'] in form_view_fields:
  File "/home/odoo/src/enterprise/19.0/worksheet/models/worksheet_template.py", line 378, in _get_qweb_arch_omitted_fields
    'x_%s_id' % self.res_model.replace('.', '_'), 'x_name',  # redundant
  File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1657, in __get__
    record.ensure_one()
  File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 5942, in ensure_one
    raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: worksheet.template(3, 14, 18)
```

OPW: 6389190

Forward-Port-Of: odoo/enterprise#126773

When attempting to refund orders that were created with the "Consumidor Final" customer. The refund validation would crash with a TypeError instead of showing the proper error message.

Steps to reproduce:
-------------------
In POS with l10n_ec_edi module activated:
* Create a new order with "Consumidor Final" as customer
* Add products and pay the order
* Validate the order
* Attempt to refund this order

> Observation:
The refund validation would crash with:
TypeError: Cannot read properties of undefined (reading 'add') at OrderPaymentValidation.isOrderValid

Why the fix:
------------
The code was trying to access `this.dialog` which is undefined in the OrderPaymentValidation class context. The dialog service should be accessed via `this.pos.dialog`, which is the correct pattern used throughout the base OrderPaymentValidation class. This fix ensures the error dialog is properly displayed when attempting to refund orders for the anonymous final consumer, instead of crashing with a TypeError.

opw-6427113

Steps to reproduce:
1. Install Documents
2. In the Documents list view, select a document to display the inspector.
3. Edit a field such as Owner or Customer which uses a Many2one widget.
4. In the field dropdown, click "Search More..." to open a modal dialog.
5. Click inside the "Search More..." modal (e.g., to sort columns or resize headers).

Issue:
- The modal dialog immediately closes, and the contact cannot be selected.

Root cause:
- When an inspector field is edited, the record row is put into edit mode. While in edit mode, the documents list renderer listens for global clicks. Clicking inside the "Search More..." modal dialog targets elements that have `.o_list_renderer` (since the modal dialog renders a list view). Because the click target is within a list renderer but is not a document row, `DocumentsListRenderer.onGlobalClick` executes and clears the selection of the main list view. Clearing the selection unmounts the edited field in the inspector, thereby destroying the modal dialog stack.

Solution:
- Modify DocumentsListRenderer.onGlobalClick to scope click handling to the current Documents list renderer.
Ignore clicks outside this.root.el, so interactions in nested UI such as Search More... do not clear
the main selection and destroy the inspector field.


opw-6253360

Forward-Port-Of: odoo/enterprise#119262

**Steps to reproduce:**
- Checkout the source code before this commit: https://github.com/odoo/enterprise/commit/57e999b6a0d0639a09ee3518045669b3258eeb8f

- Install Accounting and l10n_mx_edi

- Checkout the source code after the commit

- Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE)
- Make sure that "Outstanding Receipts accounts" are set on the Bank journal
- Create an invoice:
  * Customer: [any] (e.g. Acme Corporationà
  * Payment Way: Efectivo
  * Payment Terms: [10 Days after End of Next Month] (in order to set "Payment Policy" to "PPD")
  * Product: [any]
  * Quantity: 1.0
  * Price: 295.17
  * Taxes: 16%
- Confirm the invoice
- Send CFDI
- Register payment
- "Upate Payments" from the invoice

**Issue:**
The payment CFDI is in error:
`Code : CRP20274
Message : El campo ImporteP que corresponde a Traslado, no es igual a la suma de los importes de los impuestos registrados en el documento relacionado donde el impuesto del documento relacionado sea igual al campo ImpuestoP de este elemento y la TasaOCuotaP del documento relacionado sea igual al campo TasaOCuotaP de este elemento.`

**Cause:**
This commit https://github.com/odoo/enterprise/commit/57e999b6a0d0639a09ee3518045669b3258eeb8f introduces 6 decimals for the payment CFDI taxes.
However, if `l10n_mx_edi` module is not upgraded, the required changes in `l10n_mx_edi.payment20` template won't be applied and the amounts will not sum up correctly.

opw-646062