### **Steps to reproduce:**
- Install Payroll and Attendance apps.
- Create an employee with a flexible working schedule and work entry source as attendance.
- Create an attendance record for this employee.
- Create and compute a payslip for this employee.

### **Observed Behavior:**
 Worked Day lines are not generated, and Basic Wage is calculated as 0.

### **Expected Behavior:**
Worked Day lines should be populated based on attendance records.

### **Root Cause:**
During payslip computation, [_compute_worked_days_line_ids](https://github.com/odoo/enterprise/blob/4339010eb1e1633a67573d08e032f3922b0bec49/hr_payroll/models/hr_payslip.py#L1846) only generated work entries for versions having a `resource_calendar_id`  at [1]. As a result, fully flexible employees without a working schedule were excluded from work entry generation, preventing worked day lines from being computed.

[1]- https://github.com/odoo/enterprise/blob/4339010eb1e1633a67573d08e032f3922b0bec49/hr_payroll/models/hr_payslip.py#L1890-L1898

### **Fix:**
Remove the `resource_calendar_id` filter when calling `generate_work_entries` in `_compute_worked_days_line_ids` so work entries are also generated for fully flexible employees using attendance-based work entries.

**opw-6146452**

Forward-Port-Of: odoo/enterprise#117409

Scenario:

- set up turnstile
- with recent safari mac os or ios (reproduced from 26.2) go to
  /web/login page in a private window
- enter login and password and pass the turnstile challenge
- click on Log in

Result: nothing happens and there is an error in the console "An invalid
form control with name='' is not focusable."

Cause:

By default Safari has the Settings > Advanced > "Use advanced tracking
and fingerprinting protection" set to "in Private Browsing".

If this options is enabled in private browser or in all browsing, you
can't login to Odoo with turnstile because safari is preventing the
update of the element that is preventing to send the form:

<input style="display: none;" class="turnstile_captcha_valid" required>

When turnstile challenge succeeds, a value should be set to this input
that will unlock the form, the .value property is updated but the
browser Shadow Content is not (and if we remove display:none, the input
is empty).

Fix:

I've not been able to reproduce the issue without turnstile using same
situation and iframe. We don't know Safari heuristic but the unlocking
is working if:

- we use setProperty instead of .value
- we unset required
- we remove the input
- we display the turnstile_captcha_valid input before challenge

This fix replaces setting .value by setProperty, and add a failsafe of
unsetting required.

opw-5917286
fixes #247536

Forward-Port-Of: odoo/odoo#253367

Importing attendees on an event that has an `after_sub` mail scheduler (the default on every event) fails with `savepoint "..." does not exist` and the import is aborted.

[`_update_mail_schedulers`](https://github.com/odoo/odoo/blob/b2f3270271f6/addons/event/models/event_registration.py#L298) runs the attendee scheduler synchronously on every registration create. The scheduler commits after each mail batch, which is fine from cron but problematic during an import: since [29460b723f49](https://github.com/odoo/odoo/commit/29460b723f49) [`load`](https://github.com/odoo/odoo/blob/b2f3270271f6/odoo/orm/models.py#L884) uses a single savepoint for the whole run, and any commit underneath releases it, so the next `ROLLBACK TO` / `RELEASE SAVEPOINT` raises `InvalidSavepointSpecification`.

When `import_file` is in context, trigger the cron like the async path already does so the mails are queued instead of running inline.

Steps to reproduce:

0. Have Contacts and Events installed
1. Events > Events, create a published event
2. Open the event, Attendees tab > Favorites > Import records
3. Upload a file with new attendees (Name, Email, no external id)
4. Click Import

=> "savepoint ... does not exist", import fails

Ticket [link](https://www.odoo.com/odoo/project.task/6124741)
opw-6124741

Forward-Port-Of: odoo/odoo#267586
Forward-Port-Of: odoo/odoo#260648

## The Problem
When computing a future leave balance, `_get_future_leaves_on` triggers
`_process_accrual_plans`, which iterates period by period and calls
`_get_leaves_taken` at each step. `_get_leaves_taken` re-enters
`_get_consumed_leaves` with `ignore_future=True`, but other accrual
allocations on the same employee were not guarded by `precomputed_allocations`,
causing `_get_future_leaves_on` to fire again for each of them, launching
another full accrual run recursively. With N periods and K allocations,
total work grew as $O(N^K)$.

## The Solution
Adding `not ignore_future` to the guard prevents future projection in any
nested context where it is both semantically incorrect and the source of
the blowup.

---

## Benchmarks
*Tested on a customer database with an employee having 2 accrual allocations and
pending future leave requests 6 months out:*

| | Queries | Request Time | Improvement |
| :--- | :--- | :--- | :--- |
| **Before** | 220K | 145.0s | — |
| **After** | 2.7K | 2.8s | **-98%** |

**Note:** More optimizations could be done to reduce the queries to a constant. However given the current design, it would be a bit big change and the current performance is already acceptable.

**OPW-6115804**

Forward-Port-Of: odoo/odoo#261172

Opening the Inventory Valuation report iterated every storable product to compute total_value, which on large catalogs used several GB of RAM and timed out workers.

The report now searches only products that have stock (under the same valuation context that total_value uses) or that are lot-valuated, and feeds that smaller set into stock_value and stock_accounting_value. For historical (at_date) reports the search runs with to_date in context so qty_available is scoped to that date. _get_accounts_by_product() also switches to search_fetch so only categ_id is loaded upfront.

Benchmarks were measured on a customer database restore with ~360k storable products. After filtering, ~2.5k products feed into the valuation today and ~2.2k for a historical date.

Benchmark opening Inventory Valuation report (Accounting)
| Date       | Before | After  | Speed up |
|------------|--------|--------|----------|
| Today      | ~88s   | ~2s    | 41x      |
| Historical | ~245s  | ~173s  | 1.4x     |

The historical improvement is more modest because stock_value still has to compute total_value at the historical date for the remaining products, which traces SVL/stock.move history; the filter eliminates the dominant per-product overhead today but only the tail in the historical case.

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#265931
Forward-Port-Of: odoo/odoo#254010

Cause:
----------------------------------------
Commit 121806b57816d0fbd48b5538d2a8beae35905d99 added a test verifying that the duration in German is correctly recognized. In the test, "2 Std. 30 Min. 45 Sek.", was supposed to be recognized as 2.5125 hours. But on some browser versions it fails, as in the latest Chrome version.

This is because we use `DurationFormat()` to get the localized units. This method is supported by all browsers and will use the browser's data to get the translations. This data comes from [Unicode CLDR](https://cldr.unicode.org/) which is updated regularly.

We would need to change the test depending on the Chrome version, so we just delete it. It appears that for German hours the CLDR definitions have historically shifted between two distinct representations: "Std." and "h"

As an example:
- CLDR 47:
https://github.com/unicode-org/cldr-json/blob/16f6b8578ba5fe98959034706f337674f816fc3f/cldr-json/cldr-units-full/main/de/units.json#L3526-L3527

- CLDR 48:
https://github.com/unicode-org/cldr-json/blame/4d06be52b51bb2f75688d0abe55c52a66afed790/cldr-json/cldr-units-full/main/de/units.json#L3916-L3917


So the test fails in CLDR 48 but succeeds in CLDR 47.

As the latest version of `ICU` (used by browsers) updates its dependency to CLDR 48 ([src](https://unicode-org.github.io/icu/download/78.html)) this explains why the latest Chrome version makes the test fail.

runbot-939543

Steps to Reproduce
---
1. Open the Planning module
2. Create an open shift with allocated_hours
3. Click Auto Plan
4. Click Undo on the auto-plan notification

Issue
---
Undoing an auto-plan operation triggers recomputation of allocated_hours,
causing the shift to lose its original workload value.

Current Behaviour
---
When resource_id is set to False during undo:
- _compute_allocated_hours is triggered (depends on resource_id)
- _compute_allocated_percentage is triggered (depends on allocated_hours)
- Both fields are recalculated, potentially changing allocated_hours
  from its pre-assignment value

Expected Behaviour
---
Undoing auto-plan should preserve allocated_hours at its pre-assignment
value while allowing allocated_percentage to adapt to the new context
(open slot vs assigned resource).

Fix
---
Use protecting context manager in action_rollback_auto_plan_ids
to prevent allocated_hours from being recomputed when resource_id is
removed. This allows allocated_percentage to recalculate naturally based
on slot duration while keeping allocated_hours stable.

task - 4952149

Forward-Port-Of: odoo/enterprise#119772
Forward-Port-Of: odoo/enterprise#102864

Scenario:

- set up turnstile
- with recent safari mac os or ios (reproduced from 26.2) go to
  /web/login page in a private window
- enter login and password and pass the turnstile challenge
- click on Log in

Result: nothing happens and there is an error in the console "An invalid
form control with name='' is not focusable."

Cause:

By default Safari has the Settings > Advanced > "Use advanced tracking
and fingerprinting protection" set to "in Private Browsing".

If this options is enabled in private browser or in all browsing, you
can't login to Odoo with turnstile because safari is preventing the
update of the element that is preventing to send the form:

<input style="display: none;" class="turnstile_captcha_valid" required>

When turnstile challenge succeeds, a value should be set to this input
that will unlock the form, the .value property is updated but the
browser Shadow Content is not (and if we remove display:none, the input
is empty).

Fix:

I've not been able to reproduce the issue without turnstile using same
situation and iframe. We don't know Safari heuristic but the unlocking
is working if:

- we use setProperty instead of .value
- we unset required
- we remove the input
- we display the turnstile_captcha_valid input before challenge

This fix replaces setting .value by setProperty, and add a failsafe of
unsetting required.

opw-5917286
fixes #247536

Forward-Port-Of: odoo/odoo#253367

Importing attendees on an event that has an `after_sub` mail scheduler (the default on every event) fails with `savepoint "..." does not exist` and the import is aborted.

[`_update_mail_schedulers`](https://github.com/odoo/odoo/blob/b2f3270271f6/addons/event/models/event_registration.py#L298) runs the attendee scheduler synchronously on every registration create. The scheduler commits after each mail batch, which is fine from cron but problematic during an import: since [29460b723f49](https://github.com/odoo/odoo/commit/29460b723f49) [`load`](https://github.com/odoo/odoo/blob/b2f3270271f6/odoo/orm/models.py#L884) uses a single savepoint for the whole run, and any commit underneath releases it, so the next `ROLLBACK TO` / `RELEASE SAVEPOINT` raises `InvalidSavepointSpecification`.

When `import_file` is in context, trigger the cron like the async path already does so the mails are queued instead of running inline.

Steps to reproduce:

0. Have Contacts and Events installed
1. Events > Events, create a published event
2. Open the event, Attendees tab > Favorites > Import records
3. Upload a file with new attendees (Name, Email, no external id)
4. Click Import

=> "savepoint ... does not exist", import fails

Ticket [link](https://www.odoo.com/odoo/project.task/6124741)
opw-6124741

Forward-Port-Of: odoo/odoo#267586
Forward-Port-Of: odoo/odoo#260648

## The Problem
When computing a future leave balance, `_get_future_leaves_on` triggers
`_process_accrual_plans`, which iterates period by period and calls
`_get_leaves_taken` at each step. `_get_leaves_taken` re-enters
`_get_consumed_leaves` with `ignore_future=True`, but other accrual
allocations on the same employee were not guarded by `precomputed_allocations`,
causing `_get_future_leaves_on` to fire again for each of them, launching
another full accrual run recursively. With N periods and K allocations,
total work grew as $O(N^K)$.

## The Solution
Adding `not ignore_future` to the guard prevents future projection in any
nested context where it is both semantically incorrect and the source of
the blowup.

---

## Benchmarks
*Tested on a customer database with an employee having 2 accrual allocations and
pending future leave requests 6 months out:*

| | Queries | Request Time | Improvement |
| :--- | :--- | :--- | :--- |
| **Before** | 220K | 145.0s | — |
| **After** | 2.7K | 2.8s | **-98%** |

**Note:** More optimizations could be done to reduce the queries to a constant. However given the current design, it would be a bit big change and the current performance is already acceptable.

**OPW-6115804**

Forward-Port-Of: odoo/odoo#261172

Steps to reproduce:
---------------------------------------
1. Install Studio and Project app with demo
2. Go to Project App > studio > views > enable calendar view > close studio
3. Click on any project

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

Issue:
---------------------------------------
The traceback is yielded from the `get uniqueId` getter from the `Many2OneAvatarUserField` component:
https://github.com/odoo/odoo/blob/be8b1bbad757fda27df579ce36cbc97324f58f62/addons/mail/static/src/views/web/fields/many2one_avatar_user_field/many2one_avatar_user_field.js#L48-L50

where `write_date` is undefined. This getter was added by, https://github.com/odoo/odoo/commit/3732ca85b03bea9eabfb05cc306ce0bf5bac88d4#diff-94c14c7d2a5fe89c7558f5dffbd6cd126bcba0b140e821ef317f25ac15eb9352 which handled the case of undefined `write_date` for the related Kanban component
https://github.com/odoo/odoo/blob/c3172d65db44c41f5619aef20532c3846494ea0e/addons/hr/static/src/views/fields/many2one_avatar_employee_field/kanban_many2one_avatar_employee_field.js#L49-L52

For the Kanban record for User Avatar, a similar solution is applied in this problematic getter. https://github.com/odoo/odoo/pull/251000/changes/80b5e529304ad9a0bdaf55a49e64ac8097a0380a

Solution:
---------------------------------------
Handle missing `write_date` safely using optional chaining to avoid undefined errors

Similar fix applied for the employee avatar in https://github.com/odoo/odoo/pull/260069/changes/6658b41310106bb4e425ae537a1af6a8ed71f864

Note:
---------------------------------------
For `saas-19.3` It is solved in commit https://github.com/odoo/odoo/commit/8847084c14ae4e0595eed7e006c58e161ce450ea

opw-6210249

When a mailing is managed by a marketing automation campaign, its target domain is dynamically handled by the campaign's activities. If a user clicks the "Retry" button directly on the mailing template, it bypasses the campaign filters and queues the mailing for the entire target model, causing unintended mass spam.

This commit fixes the issue by:
1. Raising a UserError in `action_retry_failed` if the mailing is linked to marketing automation (`use_in_marketing_automation`).
2. Hiding the "Retry" button in the frontend view to prevent confusion.
3. Adding a unit test to ensure this edge case is caught in the future.

Steps to reproduce:
1. Create a marketing campaign with a filter and an email activity.
2. Run the activity and ensure at least one email trace fails.
3. Open the mailing template via the "Templates" smart button.
4. Click the "Retry" button on the template form.
5. The mailing is placed in the standard queue, bypassing the domain and targeting all records of the underlying model.

OPW-6220106

Forward-Port-Of: odoo/enterprise#119597
Forward-Port-Of: odoo/enterprise#118759

Scenario:

- set up turnstile
- with recent safari mac os or ios (reproduced from 26.2) go to
  /web/login page in a private window
- enter login and password and pass the turnstile challenge
- click on Log in

Result: nothing happens and there is an error in the console "An invalid
form control with name='' is not focusable."

Cause:

By default Safari has the Settings > Advanced > "Use advanced tracking
and fingerprinting protection" set to "in Private Browsing".

If this options is enabled in private browser or in all browsing, you
can't login to Odoo with turnstile because safari is preventing the
update of the element that is preventing to send the form:

<input style="display: none;" class="turnstile_captcha_valid" required>

When turnstile challenge succeeds, a value should be set to this input
that will unlock the form, the .value property is updated but the
browser Shadow Content is not (and if we remove display:none, the input
is empty).

Fix:

I've not been able to reproduce the issue without turnstile using same
situation and iframe. We don't know Safari heuristic but the unlocking
is working if:

- we use setProperty instead of .value
- we unset required
- we remove the input
- we display the turnstile_captcha_valid input before challenge

This fix replaces setting .value by setProperty, and add a failsafe of
unsetting required.

opw-5917286
fixes #247536

Forward-Port-Of: odoo/odoo#253367

## The Problem
When computing a future leave balance, `_get_future_leaves_on` triggers
`_process_accrual_plans`, which iterates period by period and calls
`_get_leaves_taken` at each step. `_get_leaves_taken` re-enters
`_get_consumed_leaves` with `ignore_future=True`, but other accrual
allocations on the same employee were not guarded by `precomputed_allocations`,
causing `_get_future_leaves_on` to fire again for each of them, launching
another full accrual run recursively. With N periods and K allocations,
total work grew as $O(N^K)$.

## The Solution
Adding `not ignore_future` to the guard prevents future projection in any
nested context where it is both semantically incorrect and the source of
the blowup.

---

## Benchmarks
*Tested on a customer database with an employee having 2 accrual allocations and
pending future leave requests 6 months out:*

| | Queries | Request Time | Improvement |
| :--- | :--- | :--- | :--- |
| **Before** | 220K | 145.0s | — |
| **After** | 2.7K | 2.8s | **-98%** |

**Note:** More optimizations could be done to reduce the queries to a constant. However given the current design, it would be a bit big change and the current performance is already acceptable.

**OPW-6115804**

Forward-Port-Of: odoo/odoo#261172

**Steps to reproduce:**

- Install pos_mrp
- Make a BoM for a product
- The product must have a custom attribute, of type always
- Go to the PoS
- Make a sale, with a customer, enable Ship Later
- Go to the created MO
- The Custom Description field is not showing

**Why the fix:**

This fix was previously done by e53dae2 but it did not account for the other variants and only did the fix for the never attributes.
This is because it seemed to work with other kinds of attributes until 19.0

We now also compute the move description if we have a custom attribute. We need the never variants to have a description as well, as it is done in the sale module. This commit basically aligns the behavior to the on done in the sale module.

A test had to be changed, as we now write the description in a different way, to make it the same regardless of where the picking and moves were created from. We now won't see a difference on the MO between one created from the POS and one created through the sale module.

opw-6169257

Forward-Port-Of: odoo/odoo#263350

### Issue
When you have an invoice partially paid via a method using an Outstanding Account, the payment can be kept open, leaving the invoice considered as partially paid

If a user with only "Invoicing & Banks" rights tries to reconcile a Bank Statement with the same partner, amount, and the invoice name as the memo, the automatic reconciliation fails to properly match the payment
Instead, the invoice is incorrectly considered as Fully Paid with an unwanted extra Account Receivable line added

### Cause
When a new Bank Statement is created, `_try_auto_reconcile_statement_lines()` is called and matches the outstanding credit, which invokes `set_line_bank_statement_line()`
This function creates a balancing line and triggers `move._compute_checked()` to update dependencies

However, `move.checked` requires `_is_user_able_to_review()` to be True
A user with "Invoicing & Banks" rights lacks the `account.group_account_user` group, meaning the move is not marked as checked, preventing dependencies from computing correctly
Consequently, the statement line's `amount_residual` is not cleared and the line is not removed from `remaining_st_line_ids`

Later in the process, `_try_auto_reconcile_statement_lines()` is called again with `with_user(SUPERUSER_ID)`
Because the payment matching was never finalized in the previous step, the engine fallback matches against the full invoice, adding an incorrect Account Receivable line to close it

### Steps to reproduce
- Install `accountant`
- Go to Accounting / Configuration / Accounting / Journals
- Open the Bank, under Incoming Payments tab, set the Manual Payment method's Outstanding Receipts account to 101403 Outstanding Receipts
- Update the Demo user's accounting rights to Invoicing & Banks
- Log in with the Demo user
- Create and confirm an invoice for Acme Corporation (Amount: $1100)
- Register a payment on the invoice (Amount: $500, Keep open)
- Copy the invoice name
- Open the Bank Reconciliation widget from the Accounting Dashboard
- Create and add a new Bank Statement Line (Label: Invoice name, Partner: Acme Corporation, Amount: $500)
Before the fix, an unexpected Account Receivable line is created and the invoice is marked as Fully Paid

### Notes
Instead of processing the entire block under SUPERUSER_ID, which would hide the creator identity in logs and chatter, the context key `skip_account_review_check=True` is injected during the automated statement line reconciliation
This safely bypasses the group check inside `_is_user_able_to_review` for this specific automated flow

A fallback using `.with_user(SUPERUSER_ID)` is already implemented twice within the same `_try_auto_reconcile_statement_lines` method for this specific use case, but avoiding it here preserves data auditability

opw-6077137

Scenario:

- set up turnstile
- with recent safari mac os or ios (reproduced from 26.2) go to
  /web/login page in a private window
- enter login and password and pass the turnstile challenge
- click on Log in

Result: nothing happens and there is an error in the console "An invalid
form control with name='' is not focusable."

Cause:

By default Safari has the Settings > Advanced > "Use advanced tracking
and fingerprinting protection" set to "in Private Browsing".

If this options is enabled in private browser or in all browsing, you
can't login to Odoo with turnstile because safari is preventing the
update of the element that is preventing to send the form:

<input style="display: none;" class="turnstile_captcha_valid" required>

When turnstile challenge succeeds, a value should be set to this input
that will unlock the form, the .value property is updated but the
browser Shadow Content is not (and if we remove display:none, the input
is empty).

Fix:

I've not been able to reproduce the issue without turnstile using same
situation and iframe. We don't know Safari heuristic but the unlocking
is working if:

- we use setProperty instead of .value
- we unset required
- we remove the input
- we display the turnstile_captcha_valid input before challenge

This fix replaces setting .value by setProperty, and add a failsafe of
unsetting required.

opw-5917286
fixes #247536

Forward-Port-Of: odoo/odoo#253367

Rework the in-call/meeting experience in Discuss:

- Add a "Your Meeting is Ready" banner shown while alone in a call, surfacing the permanent share link and a shortcut to invite people; it hides once another participant joins. Starting a "New Meeting" no longer auto-opens the invite panel.
- Add an "Adjust view" dialog to pick the meeting grid layout (auto, tiled, spotlight, sidebar, discuss); the choice is persisted in user settings. Layout actions (Adjust view, Picture in Picture) move into a "More" menu in the call bar, while Fullscreen keeps its own corner button and Exit Fullscreen sits next to Chat in fullscreen.
- Mirror the meeting share link in the address bar while in a call and restore the regular Discuss URL once it ends.
- Starting a meeting now enters fullscreen and auto-hides (unpins) the meeting channel from the sidebar.
- Open the invite UI as a single centered dialog everywhere (openChannelInvitationDialog); the member-list button reads "Add People" in the meeting view. Drop the "Generate new invite link" button.

Along the way, tidy up the Discuss sidebar and messages:

- Only show the Bookmarks mailbox when it holds at least one message.
- Move "View hidden conversations" out of the sidebar (still reachable from the command palette) and restyle the "New Meeting" button.
- Keep fewer inline message quick actions (3 instead of 4): Copy Text and Copy Link move to the expanded actions menu, and "Copy Link" is renamed "Copy Message Link".
- Simplify the meeting channel name, e.g. "Meeting, Jan 1".

task-6260047

## Issue
In the *Data Cleaning* app, when grouping records, the record IDs are summed up and appear right next to the name of each group, which:
1. truncates the name and count of the groups
2. does not make sense (summing up IDs is pointless)

<img width="709" height="374" alt="6166623-before" src="https://github.com/user-attachments/assets/9d80b1ec-49c0-4b7f-8c6e-53846f9e433e" />

## Steps to reproduce
1. Install *Data Cleaning* (`data_cleaning`)
2. In Data Cleaning > Configuration > Field Cleaning, create a new rule (or edit an existing one):
    - Any name
    - Model: *Contact*
    - Rule:
        - Field to Clean: *Name (Contact)*
        - Action: *Set Type Case* - Case: *All Uppercase*
4. Click the *Clean* button in the upper left corner
5. In Data Cleaning > Field Cleaning, group the records by any field (e.g., *Field*)
6. **The name of the group (_Name (Contact)_) is truncated, making it and the record count unreadable. This is due to the sum of _Record ID_ being displayed in the same row, even though that information is irrelevant.**

## Cause
The *Record ID* (`res_id`) field is an Integer field defined [here](https://github.com/odoo/enterprise/blob/3603afdd5c0d19c9276f3855156be4040ab5717d/data_cleaning/models/data_cleaning_record.py#L20). By default, Integer fields have the `sum` aggregator:

https://github.com/odoo/odoo/blob/681610c002a310f1c73fc2e5bec8d3dae27bc4a7/odoo/orm/fields_numeric.py#L17-L23

This causes the IDs to be summed up and appear in the group headers.

## After

<img width="740" height="370" alt="6166623-after" src="https://github.com/user-attachments/assets/a42d8f58-06dc-4308-8b6f-1ab09e8034f8" />

related: https://github.com/odoo/odoo/pull/265163

opw-6166623

### Issue
Since the introduction of the Tax Returns feature in 18.3, it was no longer possible to generate a Closing Entry as the button has been replaced by Returns
The Return mechanism implies that you need a Return Type in order to make a Closing Entry using the Validate button

Additionally, using the Generic Tax Report by default creates a risk in Multi-VAT environments, as it mixes taxes from all countries instead of isolating Peruvian taxes

### Cause
The new 18.3 accounting workflow requires at least one active Return Type associated with a country-specific report variant to display the Return options and process the closing entry Peru was relying on the Generic Tax Report, without a dedicated report variant
No Return Type was configured, which blocked Odoo's automatic VAT closing workflow and prevented the system from prompting the user to configure the required closing accounts

### Steps to reproduce
- Install `l10n_pe_reports` and `accountant`
- Switch to a PE Company
- Go to the Tax Report

Before the fix, no Returns button is available for any of the existing reports, making it impossible to use Odoo's automatic process to configure the tax accounts and trigger the closing entry

### Notes
This is fixed by creating a dedicated Peruvian tax report variant directly in Enterprise that inherits from the generic tax report A custom handler is added to force the domain filtering on Peruvian taxes only, and a corresponding Return Type is defined to restore the full closing entry process safely

opw-5978673

Forward-Port-Of: odoo/enterprise#117891

### Steps to reproduce:

- In the settings enable: "Units of Measure & Packagings", "Storage Locations"
- Create a product in units and register 1 unit in stock
- Inventory > Operations > Adjustments > Physical Inventory
- Select your line and request a count > Set Current Value
- Inventory > Configurations > units of measures > UOM categories
- Select unit and archive it
- Go to the barcode app > Click Count inventory
### > Owl error: Uncaught promise

### Cause of the issue:

Since the uom used on the quant is archived, it is not found by the search used to fill the barcodeCache:
https://github.com/odoo/enterprise/blob/26546bcd3beebc7f65ce08385441b6284b46598e/stock_barcode/static/src/components/main.js#L209-L213 https://github.com/odoo/enterprise/blob/26546bcd3beebc7f65ce08385441b6284b46598e/stock_barcode/models/stock_quant.py#L104-L106 https://github.com/odoo/enterprise/blob/26546bcd3beebc7f65ce08385441b6284b46598e/stock_barcode/static/src/components/main.js#L229 https://github.com/odoo/enterprise/blob/26546bcd3beebc7f65ce08385441b6284b46598e/stock_barcode/static/src/models/barcode_model.js#L37-L39 However, if the uom is not present in the barcode cache the `BarcodeQautnModel` will fail to createLinesState whihc raises a missing error:
https://github.com/odoo/enterprise/blob/26546bcd3beebc7f65ce08385441b6284b46598e/stock_barcode/static/src/models/barcode_quant_model.js#L712 https://github.com/odoo/enterprise/blob/26546bcd3beebc7f65ce08385441b6284b46598e/stock_barcode/static/src/lazy_barcode_cache.js#L107-L110

opw-6250090

Forward-Port-Of: odoo/enterprise#118987
Forward-Port-Of: odoo/enterprise#118813

Currently when user adds adds quantity in barcode using lots it leads to incorrect sale order quantities.

## Steps to replicate:
- Install Sales and Barcode (no demo data).
- Enable Lots & Serial Numbers in settings.
- Create Test Product with Tracking by Lots.
- Go to Inventory > Products>Lots & Serial Numbers and create 3 lots for the product.
- Update each lot’s on-hand quantity to 10 from the product page.
- Create and confirm a Sales Order for the product (lines: qty 3 and 2 units).
- Open the delivery in the Barcode app:
   - Scan lot 2 > increase qty to 3 using +1 button
   - Scan lot 3 > increase qty to 2 using +1 button
- Validate and go to the sale order.

## Observed Behavior:
The sale order delivered quantities are flipped and a backorder is created even though the quantity for the product is satisfied.

## Root cause:
The issue occurs because when a sales order is confirmed, the system defaults to
 using lot 1 on the delivery receipt. When a user scans lot 2, the `_processBarcode` function is triggered, which calls `_findLine` at [1] to select the appropriate line on the receipt.

As the loop in `_findLine` iterates through `pageLines` with values like: 
```
[{display_name: "Test product", quantity: 3, lot_id: { name: 'lot1' }}, 
{display_name: "Test product", quantity: 2, lot_id: { name: 'lot1' }}]
```

During the first iteration, `foundLine` is set at [2] for the line with quantity 3 . Since the subsequent if condition is not satisfied, the loop hits the continue block at [3].
On the next iteration, the line with quantity 2 causes `foundLine` to be overwritten at [2], and the continue block is executed again at [3].

This results in the line with quantity 2 being selected as the line to update at the end of the function.

When the user manually increases the quantity to 3, the line that originally required quantity 2 is updated and fulfilled.
Later, when lot 3 is scanned, the line that required quantity 3 is selected for update, and manually increasing the quantity to 2 before validating the order leads to a backorder and causes the delivered quantities to be flipped.

[1]:
https://github.com/odoo/enterprise/blob/81eaeb4b18d849c644160234def6c69013591abe/stock_barcode/static/src/models/barcode_model.js#L1335-L1337 [2]:
https://github.com/odoo/enterprise/blob/81eaeb4b18d849c644160234def6c69013591abe/stock_barcode/static/src/models/barcode_model.js#L1690-L1699 [3]:
https://github.com/odoo/enterprise/blob/81eaeb4b18d849c644160234def6c69013591abe/stock_barcode/static/src/models/barcode_model.js#L1727-L1729

## Solution:
Avoid grouping lines from different moves unless using batch transfers. This ensures that backorders are not created when the barcode lines are fulfilled.

opw-5423943

Forward-Port-Of: odoo/enterprise#118085
Forward-Port-Of: odoo/enterprise#109032

### Steps to reproduce:

- Enable `Lots & Serial Numbers` and `Packages` in the settings
- Create a product tracked by SN and add SN001 and SN002 to stock
- Create and confirm a delivery for 2 units
- Open the Barcode app and open the delivery
- Scan the product > Scan SN001
- Click `Put in Pack`

### Current behavior:

The created package is not displayed anywhere. Clicking Put in Pack again nests the package into another package without any visible indication to the user.

### Cause of the Issue:

The GroupedLineComponent cannot display neither the source or destination package:
https://github.com/odoo/enterprise/blob/c5bbcaeed513817fdda1f3f42f4c9b2440264174/stock_barcode/static/src/components/grouped_line.xml#L4-L21
However, our case the grouped line contains only a single line and prevents the users from viewing the sublines since the `Show Reserved Lots` is disabled on the operation type and only one lot (with additional demand) was scanned:
https://github.com/odoo/enterprise/blob/c5bbcaeed513817fdda1f3f42f4c9b2440264174/stock_barcode/static/src/components/grouped_line.js#L75-L77 https://github.com/odoo/enterprise/blob/c5bbcaeed513817fdda1f3f42f4c9b2440264174/stock_barcode/static/src/components/grouped_line.js#L44-L55

opw-6237834

This PR is one of many triggered by responses from Luxembourg auditors. See PR #113316 for a full list of these PRs.

As described in PR #117799, the \CustomerID and \SupplierID elements on \Transaction\Line elements is determined by a partner's `customer_rank` and `supplier_rank`.  This is a binary designation, one or the other.

The Luxembourg FAIA report requires that less than 30% of \Transaction\Line elements with payable accounts (class 6) can not have \SupplierID. The same applies for \Transaction\Line elements with receivable accounts (class 7) and the \CustomerID element.

TSB clarified that any partner on an receivable or payable line should be added to the Customer list or Supplier list respectively https://github.com/odoo/enterprise/pull/100749#issuecomment-3655127511. In addition, I verified that Luxembourg's analysis of four separate FAIA files (from ticket 5427296) aligns with this expectation. 

<img width="1322" height="690" alt="image" src="https://github.com/user-attachments/assets/1a82f99e-5b32-4dbb-96e1-1b25bab2629b" />

This commit adds partners to the \Supplier and \Customer lists if they have any payable or receivable lines, respectively. It also picks between the \CustomerID and \SupplierID based on a line's `account_type`. This logic is applied to `account_saft` and updates the other, country-specific SAFT reports where appropriate. 

It also retains the previous `customer_rank` and `supplier_rank` logic as a fallback for older XML reports and for accounts other than `asset_receivable` or `liability_payable`.

opw-6118024

Forward-Port-Of: odoo/enterprise#118714

Steps to reproduce
1. With a Mexican POS configured, create a POS order and sign a Global Invoice for it.
2. Open a new session and partially return the order; close the session.
3. On the original order, cancel the Global Invoice through the CFDI page.
4. Try to create a new Global Invoice for the original order.

Issue
The wizard raises "Orders <REFUND-NAME> are already sent or not eligible for CFDI."

Validating the refund auto-signs an `invoice_sent` CFDI on the refund pos.order because its parent is `global_sent`, see `_l10n_mx_edi_check_autogenerate_cfdi_refund` at https://github.com/odoo/enterprise/blob/5af8048f0b0956a024d7eaeb10600eec74bdf3ee/l10n_mx_edi_pos/models/pos_order.py#L98. Cancelling the GI only flips its own document to `ginvoice_cancel`; the refund's `invoice_sent` doc stays untouched, so the refund's computed `l10n_mx_edi_cfdi_state` stays `'sent'`. The chain check in `_l10n_mx_edi_check_orders_for_global_invoice` at https://github.com/odoo/enterprise/blob/5af8048f0b0956a024d7eaeb10600eec74bdf3ee/l10n_mx_edi_pos/models/pos_order.py#L184 then rejects the refund as already sent and the new GI cannot be created.

opw-6181136

Steps to Reproduce:
1. Install Accounting module (without Point of Sale).
2. Create a customer.
3. Create a journal entry with that customer set only at line level.
4. Post the journal entry.
5. Open the customer form.

Issue:
The Due smart button is not visible on the partner form even though an outstanding balance exists for the customer.

Note: This issue does not reproduce when Point of Sale is installed, as the POS module overrides `_compute_has_moves` with its own implementation that checks the outstanding balance directly.

Root Cause:
The `_compute_has_moves` method queries only `account.move `for partner matching. When a partner is referenced only at the account.move.line level, the partner is never picked up by this query, resulting in `has_moves = False` and the Due button remaining hidden.

Fix:
Replaced the EXISTS-based implementation with a UNION-based approach as the EXISTS implementation evaluated the query per partner row, whereas UNION processes all partners in a single batch query. Additionally extended the UNION to also include account.move.line partner matching, ensuring partners referenced only at the line level, are correctly detected and has_moves is set to True.

Result:
The Due smart button is now correctly visible for all partners with an outstanding balance, regardless of whether the partner is set at the journal entry level or only at the line level.

owp = 6243562

**Steps to reproduce:**

- Make a sale in the frontend
- Refund it on the order in the backend
- Reload the frontend page, the order is automatically set as the current one
- Try to pay for it
- There are 2 lines on the ticket, and the total is thus wrong

**Why the fix:**

A line that has been refunded through the backend will appear twice in the receipt, causing it to be wrong.

When loading the order from the backend, when we refresh the page after refunding it from the backend, we load the order and it's lines. The lines are found but they don't have any uuid set, so the pos sets one.

Then at paying time, we load them again to check that nothing changed, but when loading the lines, we see that it does not have a uuid, as we did not write the frontend uuid to the backend yet.
https://github.com/odoo/odoo/blob/0b17840fb3cc72935e1a6302a057fb55c253c498/addons/point_of_sale/static/src/app/store/pos_store.js#L1277-L1279
As we see we don't have a uuid on the line, we set it. The line is found again in the data in the snipped above.
The line is then considered missing from the missingRecursive function, and when we try merge them with the existing lines, they don't have the same uuid so they are treated as different.

This means we set 2 different uuids to a line that was in fact the same. The pos then sees 2 lines with 2 differents uuids, so it treats them as 2 different lines and we have to pay for both, even though they are the same and the second one should not have been added to the order and should have been ignored.

Without this fix, the pos will think we don't have the line yet, even though we do, but just with another uuid so it will add it to the order even though it should not. We will then have the same line with two different uuid, so it will be considered as 2 different lines and both will be added to the receipt and have to be paid for.

With this fix, the two lines now have the same uuid, and will be treated as the same line, as it should.

opw-6235870

Description of the issue/feature this PR addresses:
When an orderpoint fails during a portal user's transaction (e.g., eCommerce checkout), the system catches the `ProcurementException` and logs a warning activity on the product template. The exception handler uses `.sudo().activity_schedule()`, which bypasses the write access restriction but leaves `env.uid` as the portal user. Therefore, the restricted portal user permanently becomes the `create_uid` (Author) of the activity.
 System exception activities should always be authored by the system (OdooBot), never by a portal or public user. This context leak corrupts the activity metadata by injecting an external user ID into internal backend logs.
Chain `.with_user(SUPERUSER_ID)` to the `.sudo()` call in `stock_orderpoint.py` when scheduling the exception activity. This ensures the environment context is stable and the activity is authored by OdooBot, which transcends multi-company record rules.
    Steps to Reproduce on Runbot/Fresh Database on version 18.0:
    1. Enable Multi-Company with Company A and Company B. Set Company B as the active company for the website.
    2. Restrict the main Admin (Runbot) user strictly to Company A.
    3. Create a Shared Product (Company field left blank).
    4. Set a Reordering Rule (Orderpoint) for the product that is guaranteed to fail routing.
    5. Navigate to the frontend website and sign up as a new user (this creates a Portal User in Company B).
    6. As the newly signed-up Portal User, complete an eCommerce checkout for the shared product.
    7. The checkout succeeds, but the backend triggers the orderpoint failure and logs the exception activity on the product template.
    8. Check the `mail.activity` record for this product: the `create_uid` is incorrectly set to the Portal User instead of OdooBot (1).
    9. (In 19.0 Upgrade) Log in as the Admin user (set strictly to view Company A), navigate to the product, and the AccessError for reading will appear due to this leaked id.
    
[opw-6253978](https://www.odoo.com/odoo/my-support-tasks/6253978?debug=assets)

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

Leaving a session open and idle (page open, no activity at all) eventually pops an error dialog:

    UncaughtPromiseError > RequestPendingError
    REGISTER request already in progress, waiting for final response
        at Registerer.register (sip.js)
        at Registerer.register (registerer.js)
        at UserAgent.attemptReconnection (user_agent_service.js)

When the WebSocket transport drops while a REGISTER is in flight (which happens on an idle tab: SIP.js sends a periodic re-REGISTER before the registration expires, and the socket may be closed by an idle timeout or by the machine going to sleep in the meantime), the final response never comes back. SIP.js only clears its internal `waiting` flag from the REGISTER response callbacks (onAccept/onReject/onRedirect); it is never reset on transport loss or request timeout. The Registerer is then stuck `waiting` forever, and every subsequent register() rejects with a RequestPendingError.

On top of that, our wrapper's register() did not return the SIP.js promise, and attemptReconnection() called it without awaiting, so the rejection escaped the surrounding try/catch and surfaced as an unhandled promise rejection. Worse, the WebSocket error was resolved right after, so the user appeared reconnected while VoIP registration was actually dead until the page was reloaded.

This commit makes register() recreate the underlying SIP.js Registerer when it is stuck `waiting` (a clean instance starts with waiting=false), and return the promise so callers can await it. attemptReconnection() now awaits it, so any rejection goes through the existing retry/back-off logic instead of bubbling up as an uncaught error.

The recreation is intentionally conditional: disposing a healthy registerer would send an unregister (REGISTER expires=0) racing with the fresh register (expires=600) and could leave us unregistered, so we only recreate when a request is actually stuck.