Currently, an error occurs when user tries to group by an analytic plan on depreciation schedule.

Steps to replicate:
- Install `accountant` with demo, turn on `Analytic Accounting` from settings.
- Open `Accounting > Review > Depreciation Schedule`.
- Click `Analytic` > Add a `Plan`.

Error:
```
psycopg2.errors.UndefinedFunction: operator does not exist: text = record
LINE 12:             WHERE key IN (('7', '16', '8', '15', '6', '9', '...
                               ^
HINT:  No operator matches the given name and argument types. You might need to add explicit type casts.
```

Cause:
- At line [1], we pass a tuple of `analytic_account_ids`, which is then wrapped again in parentheses at line [2].

- This results in the IDs being enclosed in double parentheses, e.g. `(('7', '16', '8', '15', '6'))`.

- When the `IN` clause is used with this double-parenthesized tuple, PostgreSQL treats it as a list containing a single record. It then tries to compare `key` (a text value) with that record `('7', '16', '8', '15', '6')`, effectively resulting in a `text = record` comparison, which is invalid and causes error.

Solution:
- Removed the extra parentheses from the query.

[1]: https://github.com/odoo/enterprise/blob/847b5be291adbfa315f8f74ab7a6dd3d1fb7d518/account_asset/models/account_assets_report.py#L124

[2]: https://github.com/odoo/enterprise/blob/847b5be291adbfa315f8f74ab7a6dd3d1fb7d518/account_asset/models/account_assets_report.py#L121

sentry-7423121981

Forward-Port-Of: odoo/enterprise#114334

### Issue:
When sending invoices to Chorus Pro via Peppol in France, SIRET numbers may contain spaces, causing the document to be silently rejected

### Cause:
SIRET values must be exactly 14 characters long
However, spaces were not removed when generating the XML, leading to invalid values in:
`<cbc:ID schemeID="0009">` and `<cbc:CompanyID schemeID="0009">`

This issue can occur for both the company and the customer SIRET, as both rely on `company_registry`

As a result, Chorus Pro rejects the document due to invalid SIRET length

### Steps to reproduce:
- Install `l10n_fr_facturx_chorus_pro` and switch to `FR Company`
- Enable and Activate Peppol in Settings
- Go in Settings > Users & Companies > Companies and open the `FR Company`
- Add spaces in the Company ID: 968 515 7590 5808
- Create a Customer (Country: France, VAT: FR23334175221, Company ID/Siret: 123 456 7890 1234)
- In the customer's Invoicing Tab (Invoice sending: by Peppol, eInvoice format: EU Standard (Peppol Bis 3.0), France SIRET: 11000201100044)
- Create and Send an invoice via Peppol (Your Customer, any line with a tax)
- Open the XML
- Check the IDs and CompanyIDs in the document Before the fix, there is missing spaces

opw-6047840

Forward-Port-Of: odoo/odoo#260578

When a menu item URL contains a space and has no leading slash (e.g.,
"some url"), creating a page from its 404 screen does not link the menu
to the newly created page. The menu keeps pointing to a 404.


**Steps to reproduce**:
1. Create a menu item with a URL containing spaces and no leading slash
   (e.g., "some url").
2. Click the menu item -> a 404 page is displayed (expected).
3. Click "Create Page" -> the page is created and saved.
4. Click the menu item again -> it still returns a 404 (unexpected).


**Issue**:
During page creation, the path is slugified (e.g., "some url" ->
"/some-url"). The controller then tries to link the menu to the new page
by setting `page_id`. However, `pagenew()` only searches for menu URLs
with a leading slash, so a menu saved as "some url" is not found when
searching for "/some url". As a result, `page_id` is never set, and
`_clean_url()` keeps resolving the menu to "/some url" instead of the
page's actual URL "/some-url".

Menus without spaces (e.g., "mypage") have the same issue where
`page_id` is not set, but since `_clean_url()` prepends "/" and renders
"/mypage", which matches the new page URL, the menu still resolves
correctly.


**Fix**:
Match both URL formats (with and without leading slash) when linking a
menu to a newly created page.

Additionally, a warning is now shown in the menu editor when a URL
contains spaces, since spaces are slugified during page creation,
which could cause confusion. (Note: this is only a warning - URLs with
spaces are still allowed.)

task-[5095646](https://www.odoo.com/odoo/project/974/tasks/5095646)

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

Forward-Port-Of: odoo/odoo#261208
Forward-Port-Of: odoo/odoo#248967

Before this commit, the logic that computes the invoice's DIAN state would rely solely on the state of the most recent document.

The problem with that approach is that we will regularly send status updates to DIAN after the invoice was successfully submitted via the status cron here: https://github.com/odoo/enterprise/blob/19.0/l10n_co_dian/models/account_move.py#L484
Those status updates are expected to fail a certain number of times (typically when no commercial status information is available, or in other terms when `l10n_co_dian_commercial_state` is still in `'pending'`).
As a result, an invoice successfully transmitted to DIAN could still end up with a `l10n_co_dian_state` not set to `'invoice_accepted'`.

This leads, among other things to a QR code that cannot be reprinted as the logic here: https://github.com/odoo/enterprise/blob/19.0/l10n_co_dian/models/account_move.py#L225 determines which template to render based on that state.

The issue cannot be easily reproduced or tested as `l10n_co_dian.document` are generated almost only in prod scenarios.

The most common setup where the error happens is for invoices that have 2 DIAN documents:
1. the first (oldest, bottom-most) one reflects acceptance of the invoice sending by DIAN (`state = 'invoice_accepted'`)
2. the second one (most recent, top-most), which reflects the latest query for commercial status update by the cron and which failed (`state = 'invoice_rejected'` and the error message reflects the lack of commercial events)

opw-6108318
opw-5931442
opw-6034035

Forward-Port-Of: odoo/enterprise#113929

Before this commit, editing a line with an analytic distribution caused inconsistent behavior when changing the account.

When an analytic distribution was present, editing the line created analytic lines linked to the move line. However, changing the account from the form view in the bank reconciliation widget triggered _inverse_account_id, which in turn called _inverse_analytic_distribution. This resulted in unlinking the analytic_line_ids from the move line, preventing the account change from being applied.

On a second attempt, the account could be modified because there were no longer any analytic lines to unlink. This led to orphaned analytic lines not linked to
 any journal item.

To fix this, the inverse method is now disabled while editing the line in the form view. Upon saving, the analytic_line_ids are explicitly unlinked, and _create_analytic_lines is triggered during the update to correctly recreate the analytic lines.

opw-6107329

Forward-Port-Of: odoo/enterprise#114863

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

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

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

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

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

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

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

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

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

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

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

opw-6082422

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

Forward-Port-Of: odoo/odoo#258963

Problem: Portal email with auto-assignment crashes ticket creation due to calendar access.

When a helpdesk ticket is created via email from a portal user and automatic assignment is enabled, the system computes working intervals for users to determine assignment.

This computation goes into resource logic, where resource.calendar fields (flexible_hours) are read.

If the assigned user is linked to multiple employees across companies, multiple resource.resource records are evaluated.

The helpdesk email flow starts in sudo, but the employee calendar lookup explicitly drops sudo before returning the calendar. Then, the calendar is accessed in the portal context, which does not have permission to read the other company's resource.calendar, leading to an AccessError and preventing ticket creation.

Although the failure is triggered from Enterprise helpdesk, the actual crash occurs in Odoo (resource.calendar), meaning the fix must be applied there.

Fix: Preserve sudo when fetching employee calendars to ensure that scheduling logic does not depend on the access rights of the email sender.

A test is added in helpdesk_holidays, as the issue requires both helpdesk (auto-assignment) and hr (employees/resources) to reproduce. The test simulates a portal email flow with a multi-company user linked to multiple employees and ensures ticket creation succeeds.

Steps to Reproduce:
1. Install Helpdesk, Employees, and enable multi-company
2. Create two companies (e.g., Company A and Company B)
3. Create one internal user (User X) with access to both companies
4. Create two employees linked to the same user:
- Employee 1 in Company A
- Employee 2 in Company B Make sure they are set with a start date, but no end date. Needs to be active employee.
5. Create a Helpdesk team in Company A
6. Add Agent X as a team member
7. Enable automatic assignment
8. Configure an email alias for the helpdesk team
9. Create a portal user
10. Send an email from the portal user to the alias

Related Ticket: opw-6035099

Forward-Port-Of: odoo/odoo#257720

Problem: Portal email with auto-assignment crashes ticket creation due to calendar access.

When a helpdesk ticket is created via email from a portal user and automatic assignment is enabled, the system computes working intervals for users to determine assignment.

This computation goes into resource logic, where resource.calendar fields (flexible_hours) are read.

If the assigned user is linked to multiple employees across companies, multiple resource.resource records are evaluated.

The helpdesk email flow starts in sudo, but the employee calendar lookup explicitly drops sudo before returning the calendar. Then, the calendar is accessed in the portal context, which does not have permission to read the other company's resource.calendar, leading to an AccessError and preventing ticket creation.

Although the failure is triggered from Enterprise helpdesk, the actual crash occurs in Odoo (resource.calendar), meaning the fix must be applied there.

Fix: Preserve sudo when fetching employee calendars to ensure that scheduling logic does not depend on the access rights of the email sender.

A test is added in helpdesk_holidays, as the issue requires both helpdesk (auto-assignment) and hr (employees/resources) to reproduce. The test simulates a portal email flow with a multi-company user linked to multiple employees and ensures ticket creation succeeds.

Steps to Reproduce:
1. Install Helpdesk, Employees, and enable multi-company
2. Create two companies (e.g., Company A and Company B)
3. Create one internal user (User X) with access to both companies
4. Create two employees linked to the same user:
- Employee 1 in Company A
- Employee 2 in Company B Make sure they are set with a start date, but no end date. Needs to be active employee.
5. Create a Helpdesk team in Company A
6. Add Agent X as a team member
7. Enable automatic assignment
8. Configure an email alias for the helpdesk team
9. Create a portal user
10. Send an email from the portal user to the alias

Related Ticket: opw-6035099

Forward-Port-Of: odoo/enterprise#114699
Forward-Port-Of: odoo/enterprise#113047

Steps to reproduce Bug 1:
  1. Login as a user with "All Timesheets" (Approver) access.
  2. Disable the "Timesheet Assistant" feature for this user.
  3. Ensure "Billing Rate Indicators" is enabled in settings.

Steps to reproduce Bug 2:
  1. Login as a user with "All Timesheets" (Approver) access.
  2. Disable the "Billing Rate Indicators" setting in company settings.
  3. Ensure "Timesheet Assistant" is enabled in settings.
 
Steps to reproduce Bug 3:
 1. Only install 'sale_timesheet_enterprise'.
 2. Go to Timesheets > Configuration > Settings.
 3. Toggle "Billing Rate Indicators" (timesheet_show_rates) or change the encoding unit (timesheet_encode_uom_id), then save and check the menus.

Issue:
1. The "Configuration" menu is hidden, preventing access to billing targets even if the user has "All Timesheets" access.
2. The "Billing Time Targets" menu is still visible inside Configuration even if the "Billing Rate Indicators" feature is disabled in the settings.
3. Menu visibility does not update immediately after saving the settings. Menus that should appear (e.g., "Employee Billing Time Targets" or "Timesheets Assistant") remain hidden, or vice versa, until the cache is cleared or the server is restarted.

Cause:
1. The `hr_timesheet_enterprise_menu_configuration` was restricted in XML to groups that excluded "All Timesheets" users.
2. The `_load_menus_blacklist` logic in Python only blacklisted billing menus for users who were both Managers and System Admins, leaving them visible to regular Approvers even when the feature was disabled.
3. The load_menus method is decorated with @ormcache and stored in the Registry LRU cache. Menu visibility depends on timesheet_show_rates and timesheet_encode_uom_id through _load_menus_blacklist. When this field is updated, the ORM does not automatically invalidate the cached load_menus result because these specific fields are not part of the configuration fields. As a result, the stale old menu remains in memory.

Fix:
- Updated XML to include `hr_timesheet.group_hr_timesheet_approver` in the Enterprise Configuration menu permissions.
- Refactored `_load_menus_blacklist` to:
    - Hide all billing-related menus for all users when the feature is disabled.
    - Hide the parent Configuration menu if it would otherwise be empty.
- Override the write method in res.company in both modules and explicitly call env.registry.clear_cache() when the relevant configuration fields are modified.

task-5428010

Forward-Port-Of: odoo/enterprise#106464

Steps:
- Install ai
- Open ai chat
- Try to send a message
- Traceback

The AI chat was failing on iOS with a traceback when trying to process
the stream response.

Even though MDN suggests compatibility, Safari (WebKit) versions prior
to 26.4 do not implement the AsyncIterator protocol on ReadableStream.
This makes `for await (const chunk of response.body)` throw a TypeError
as `[Symbol.asyncIterator]` is undefined.

https://developer.mozilla.org/en-US/docs/Web/API/ReadableStream

This commit replaces the async iteration with a manual reader loop
(`getReader().read()`). This is the low-level primitive supported by
all versions of Safari and ensures the stream is properly consumed and
unlocked even if the connection is interrupted.

Steps to reproduce:
1. Open Discuss/AI Chat on an iPad or iPhone (eg. 26.4).
2. Send a message.
3. The response triggers a JS error.

```js
Uncaught Promise > undefined is not a function (near '...chunk of asyncStream...')
```

opw-6054307

Forward-Port-Of: odoo/enterprise#113926