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

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

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

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

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

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

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

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

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

opw-6204049

Forward-Port-Of: odoo/enterprise#118950

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

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

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

opw-6182286

Forward-Port-Of: odoo/enterprise#116166

*= test_l10n_us_hr_payroll_account

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

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

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

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

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

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

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

**opw-6181024**

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

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

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

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

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

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

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

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

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

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

opw-6159674

Forward-Port-Of: odoo/odoo#267202

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

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

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

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

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

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

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

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

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

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

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

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

opw-6204049

Forward-Port-Of: odoo/odoo#264925

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

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

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

opw-6126760

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

*=l10n_ch_hr_payroll,hr_payroll_account_iso20022

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

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

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

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

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

sentry-7391832811

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

Before this commit, when browser window is small while not on a mobile device, clicking on the message action "Add a reaction" would lead to the following crash:

```
Cannot destructure property 'owner' of 'undefined' as it is undefined.
    at Proxy.onSelected
```

This happens because cliking on this button on small screen would immediately trigger the complete showing of the emoji picker rather than just the quick menu. While this calls `action.onSelected()` and is expected to work [1], the problem is that this was passing the action definition rather than the action object as prop. As a result, `onSelected()` was using the definition and didn't pass the expected params that are destructed in the definition.

This commit fixes the issue by passing the `action` object to `QuickReactionMenu` component, so that the `action.onSelected()` is properly passing the `action.params`.

[1]: https://github.com/odoo/odoo/blob/19.0/addons/mail/static/src/core/common/quick_reaction_menu.js#L84

Forward-Port-Of: odoo/odoo#270158

[FIX] mail_alias_domain: prevent capitalization in domain names to avoid email routing issues
    
Currently, we allow capitalization in the name / display_name field for Email Domains (mail.alias.domain), which allows for capitalized domains in email aliases. When the system receives incoming emails via mail_thread.py's message_route,
the reply_to email addresses are sanitized (all lowercase). We then use the case-sensitive 'in' to identify
message routes, which will always fail for capitalized email domains.

This PR applies sanitizing to the name field so that users cannot save capitalized email domains.

Other options are not viable because:
1. we don't have a case-insensitive equivalent of the 'in' operator
2. altering the current logic to be case-insensitive would decrease performance
3. altering the current logic would change the structure of message_route

Fixes #opw-5401633

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

Forward-Port-Of: odoo/odoo#257792

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

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

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

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

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

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

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

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

opw-6206080

Forward-Port-Of: odoo/odoo#270157
Forward-Port-Of: odoo/odoo#264738

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/e061163e2e [REL] 19.3.7 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/0d81fad529 [FIX] Headers overlay: unhide headers in dark mode [Task: 6233467](https://www.odoo.com/odoo/2328/tasks/6233467)
https://github.com/odoo/o-spreadsheet/commit/8eaa180d01 [FIX] autofill: make tooltip readable in dark mode [Task: 6289977](https://www.odoo.com/odoo/2328/tasks/6289977)
https://github.com/odoo/o-spreadsheet/commit/0e6b5108a9 [FIX] pivot: hide collapse icon when displaying formulas [Task: 6218524](https://www.odoo.com/odoo/2328/tasks/6218524)
https://github.com/odoo/o-spreadsheet/commit/d5547b637d [FIX] side_panel: autocomplete dropdown transparency issue on scroll [Task: 6254807](https://www.odoo.com/odoo/2328/tasks/6254807)

Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>

Behavior before:
Adjusting physical inventory quantities for reserved packages takes time when linked to large delivery orders (e.g., 400+ lines). The user interface freezes, causing a poor warehouse user experience during stock counts.

Behavior after:
Inventory adjustments on reserved packages process faster. The UI remains responsive, and package records are updated instantly without performance degradation.

Root Cause:
When an inventory adjustment triggers '_free_reservation', it processes move lines sequentially. Inside this loop, Odoo recursively runs '_check_entire_pack()', forcing a full database evaluation of all 400+ delivery lines for every single line adjusted. This results in heavy, redundant processing.

Fix:
Used a context flag `bypass_entire_pack=True` to silence the '_check_entire_pack()' validation while looping through individual line adjustments. Once the loop completes, the package validation is called exactly once in batch for all affected pickings, preserving data integrity while eliminating redundant database queries.

Steps to Reproduce:
1. Have a product tracked by Lot and Package.
2. Have an open delivery order in Ready state (stock reserved) containing 400 or more lines of this product, one package per line.
3. Go to Inventory → Physical Inventory.
4. Set the counted quantity of any reserved bag to 0.
5. Click Apply.
6. Observe that the system takes time to process this single change.
7. Unreserve the delivery order.
8. Perform the same steps as mentioned above.
9. Inventory adjustment is much faster.

opw-6234885

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

Forward-Port-Of: odoo/odoo#270228

When opening a profile from the avatar card, the employee's company may
not be in the user's active companies. Until now this popped a confirmation
dialog that only let the user either activate the other company or cancel,
with no way to reach the still-accessible contact profile.

Replace the dialog with a less intrusive "View Profile" dropdown, shown
only when the employee's company is allowed but not active. It offers two
choices:

- Open Employee Profile (activates the company)
- Open Contact Profile (no company activation)

Activating an extra company widens the active-company scope for the whole
session, which is not always desirable, so keeping a non-mutating path to
the contact profile is useful. In every other case (no employee, company
already active, or company not allowed) the plain "View Profile" button is
unchanged.

task-6074597



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

Forward-Port-Of: odoo/odoo#270312
Forward-Port-Of: odoo/odoo#264073

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

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

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

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

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

opw-6269478

Forward-Port-Of: odoo/odoo#270459
Forward-Port-Of: odoo/odoo#269818

**Steps to reproduce:**
- Install the `l10n_us_account` module and switch to a My US company
- Navigate to Invoicing > Configuration > Journals > Bank
- Click the internal link of the `Bank Account Number`
- Go to the `Bank Information` tab
- Observe that the `Intermediary SWIFT` field is visible
- Remove `United States` from the bank address

**Observation:**
The `Intermediary SWIFT` field becomes `invisible` when the country 
is not set to `United States`.

**Root Cause:**
At [1], the field Intermediary SWIFT( `intermediary_bank_bic`) is defined with 
a condition that makes it invisible when the country is not 'US'.

**Fix:**
This commit ensures that the `Intermediary SWIFT` field remains visible when
the company uses the US fiscal localization package, even if the bank country
is not set to United States.

[1]:
https://github.com/odoo/odoo/blob/1d4715e58613912bfd0ded4fd370c50c131ff164/addons/l10n_us_account/views/res_partner_bank_views.xml#L9

opw-6145872

Forward-Port-Of: odoo/odoo#260989