[FIX] website: translate links inline on media replacement
    
    On the website builder, files added through the `/file` command would go
    through the domPlugin `insert` method, which would call
    `before_insert_processors` and apply `.o_translate_inline` as expected.
    But there is another flow to add a document on the page: replace an
    image (or video, or icon), then select the "Documents" tab and upload
    a file. With this flow, `insert` is not called, so we have to add the
    class through some other resource.
    
[FIX] html_editor: target documents with right class
    
    The class `.o_image` was still associated with documents (in the context
    of the file selector) and the expected tag of a document was `A`, in
    spite of it not being true in `html_editor` since the introduction of
    the file box in [1].
    
    This has also been updated in the website builder since the introduction
    of the `html_builder` module in 18.4, which swapped uses of `web_editor`
    components for `html_editor`.
    
    As a side-effect, in website, a double click on a file did not open the
    media dialog on the "document" tab, unlike other media (images, videos,
    icons). In such a case, the file was also not shown as already selected
    in the media dialog (because it targetted the wrong tag name). Both of
    those behaviors were lost as we used the new file box design in 18.4.
    
    [1]: https://github.com/odoo/odoo/commit/7f9afa21dffba2f74f9fb8a68809db4af6c7c225
    
task-5876278

Forward-Port-Of: odoo/odoo#259840
Forward-Port-Of: odoo/odoo#245904

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#113047

Recent commit fixes an issue where items like Fullscreen in call menu had reduced opacity when this should only affect layout buttons in call view [1].

To do so it limits the opacity to the layout actions, but the style was not applied because ActionList has more CSS specificity that requires using `--o-mail-ActionList-Button-opacity` variable for the non-hover opacity value. Since this was not defined, this default to opacity 100%, thus not applying the reduced opacity when not mouse-hovering.

This commit fixes the issue with `--o-mail-ActionList-Button-opacity` of `.75`, so that opacity is slightly reduced when no mouse-hovering.

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

Before / After (mouse-hover on "Picture-in-Picture", see lack of visual distinction)

<img width="58" height="32" alt="Screenshot 2026-04-22 at 11 21 47" src="https://github.com/user-attachments/assets/e04b0f8c-c754-4ea4-8870-752610418587" />
<img width="57" height="28" alt="Screenshot 2026-04-22 at 11 21 25" src="https://github.com/user-attachments/assets/a5aa9987-ddaf-45f8-9e2a-260fd04dcfb9" />

Forward-Port-Of: odoo/odoo#260599

Steps to produce:
---
- Install the `Sales` module.
- Go to `Invoicing > Configuration > Payment Terms`.
- Open `Immediate Payment` and enable Early Discount.
- Set `Reduced Tax` to `Always (upon invoice)`.
- Go to Invoicing > Configuration > Taxes.
- Create a 21% tax with `Tax included`.
- Create a product with a sale price of 7.50 and assign the tax.
- Create a Sale Order with this product > Set Immediate Payment as payment term.

Issue:
---
- The untaxed amount is computed as 6.22 instead of 6.20.

Root cause:
---
- At [1], in `_add_base_lines_for_early_payment_discount`, the base lines generated for early payment discount were missing the `special_mode='total_excluded'`.
- Consequently, the tax engine interpreted these amounts as tax-included and attempted to recompute the untaxed base, resulting in an incorrect untaxed amount.

Solution:
---
- Add `special_mode='total_excluded'` to the base lines created for early payment discount computation.
- This ensures the discount amounts are treated as already tax-excluded.

[1]https://github.com/odoo/odoo/blob/a2b4f618328f3ce3f654fd2c1ee4410365706a7e/addons/sale/models/sale_order.py#L515-L550

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

Forward-Port-Of: odoo/odoo#260480
Forward-Port-Of: odoo/odoo#255724

**Steps to reproduce:**
- Install the `l10n_cz_reports` module and switch to a `CZ Company`
- Create an invoice for a customer with a VAT number, add a product, and 
  set the Transaction Code (enable it from the optional columns if needed).
- Navigate to Reporting > VIES Summary Report.
- Observe the value in the `VAT Number` column (includes country code).
- From the dropdown, export the report as XML.

**Observation:**
In the generated XML file, the `c_vat` field contains the VAT number 
including the country code (e.g., `CZ12345679`) instead of only the 
numeric part (`12345679`).

**Root cause:**
At [1], the VAT number is directly taken from the report lines without 
removing the country code.

**Fix:**
This commit ensures that the `c_vat` field contains only the VAT number without 
the country code, complying with the official VIES XML format requirements.

Ref: https://adisspr.mfcr.cz/dpr/adis/idpr_pub/epo2_info/popis_struktury_detail.faces?zkratka=DPHSHV#:~:text=Tax%20identification%20number%20of%20the%20purchaser%20(only%20the%20numeric%20part)

[1]:
https://github.com/odoo/enterprise/blob/c4f2c3442f30f5ac972dd136a3642acc5bcc6da2/l10n_cz_reports_2025/models/l10n_cz_vies_summary_handler.py#L29-L62

opw-6093259

Forward-Port-Of: odoo/enterprise#114730
Forward-Port-Of: odoo/enterprise#113083

### Issue:
When a fiscal position defines a `foreign_vat`, tax reports generated for that country still use the company's VAT number instead

For example, with a Belgian fiscal position using `BE010203040`, the generated BE VAT report uses the company VAT instead of `010203040`

### Cause:
The report generation did not check whether there is a fiscal position with a `foreign_vat` matching the country of the report

### Note:
The example above uses a Belgian fiscal position to reproduce the issue

Starting from 19.0, this specific flow is blocked because Intervat is enabled in production mode by default

A related fix makes the Intervat settings available in that case
Until then, the issue can be reproduced by temporarily commenting out: https://github.com/odoo/enterprise/blob/5fb58a9b7b3ae89f87e84d4ba1fa3a16237d80ac/l10n_be_intervat/models/account_return.py#L15

### Steps to reproduce:
- Disable demo data and install `accountant`
- Create a Fiscal Position "Belgium" (Country: Belgium, Foreign Tax ID: BE010203040)
- Click the alert to install the Belgian taxes
- Create and confirm an invoice for a Belgian customer:
  - Fiscal Position: Belgium
  - Any product with a Belgian tax
  - Invoice Date: 01/01/2026
- Open the Tax Report and select `VAT Return (BE)` for January
- Click `Returns` and select the full year
- Mark the December return as Completed from the three-dot menu
- Review January and fill the missing company data (TIN: 1111111, phone and email)
- Click `Validate -> Lock -> Submit`

### Before the fix:
The generated XML uses the company VAT number (`1111111`) instead of the fiscal position foreign VAT (`010203040`).

opw-6076540

Forward-Port-Of: odoo/enterprise#112610

Why this commit:
When loading the 'bills to receive' or 'Invoices to be Issued' The time zones ahead of UTC will face the discrepancy in the view.

e.g. etc/GMT-12 timezone is 12 hours ahead of UTC, So 12 AM UTC is 12 PM etc/GMT-12.
So report view will not include the invoices/bill with order_date of current day till its 12 AM[next day] IN UTC, Meaning etc/GMT-12 will be seeing today's bills/invoices  after 12 PM.

After this commit:
To resolve this discrepancy we use the context_today date to get the user
 local date. Which is required by the [domain sanitizer](https://github.com/odoo/odoo/blob/8bff78853f6ab8dc2cc951c03bb30181c0745834/odoo/orm/domains.py#L1572-L1574) too.
 
 Steps to reproduce (Possible in runbot) :
1. Select etc/GMT-12 timezone in preferences
[when UTC is between 13:00-24:00 ~ 1:00-12:00 GMT-12(of next day)]
2. Create a PO and Validate the quantity received.
3. Go to accounting>review>bills to receive.
4. the newly created PO won't be listed here.

OPW: 6083526

Forward-Port-Of: odoo/enterprise#114763

Users who do not have the "write" access on `product.template` and `product.product` cannot print product labels and product variant labels

Steps to reproduce:
1. Install Sales
2. Log in as Marc Demo
3. In Sales > Products > Products, open a product and click Print Labels from the cogwheel menu
4. An access error is raised Same issue happens for Product Variants

Issue:
https://github.com/odoo/odoo/commit/95ace0a694eaf83329b50e6b89f774f0c59fec5e removed Products-related rights from the `base.group_user`. This made a difference in terms of access rights, as the `IrActionServe.run` method checks for the "write" access by calling
`_can_execute_action_on_records`:
https://github.com/odoo/odoo/blob/d15685304f479541879fabd55ea1cae4252a2a90/odoo/addons/base/models/ir_actions.py#L1230-L1239

Solution:
Add `group_user` to the `group_ids` of the relevant actions to prevent the check on the "write" access from being performed
This is a backport of https://github.com/odoo/odoo/commit/6c2c353f30db05579f5e8b7a6752ec2d1ae365b2

opw-6111333

Forward-Port-Of: odoo/odoo#260513
Forward-Port-Of: odoo/odoo#260342

### Steps to reproduce:

- Create a button, set its URL to #, and click Apply.
- Place the cursor right after the link.
- Press Backspace until the button/link is removed.
- Entire editor also gets removed.

### In previous version:

- Issue is due to [1](https://github.com/odoo/odoo/commit/7685e562b1036d08724ba91ed5064b6fe20c2ce2
) change in `isEmptyBlock` (because of `isButton`).
- When we had `<a>#[]</a>` and pressed backspace, `deleteRange` was called.
- Then `fillShrunkBlocks` ran and `isEmptyBlock` returned true (no isButton).
- So `<br>` was added and block never became fully empty.

### In current version:

- Because of `isButton` condition, some empty blocks are not treated as empty.
- So `<br>` is not added & block stays actually empty. Then `removeFEFF` runs & `nodeSize` becomes false &  `cleanEmptyAncestors` removes parent even editable.

### After this PR:

- Case like `<a>[]</a>`, backspace is handled by override which directly removes `<a>`. Since this skips `deleteRange`, manually call `fillShrunkBlocks` there.
- Now after removing `<a>`, block is properly detected as empty and `<br>` gets added.

task-6109145

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

Forward-Port-Of: odoo/odoo#259055

Steps to reproduce the bug:
- Create a service product "P1":
  - In the Purchase tab:
    - Vendor: Azure Interior
    - Subcontract Service: True
  - UoM: dozen
  - Purchase UoM: unit

- Create a sales order with 1 dozen of P1
  - Confirm -> a purchase order with 12 units of P1 is generated
- Confirm the purchase order
- Go back to the sales order:
  - Update the quantity from 1 to 2 dozen

Problem:
A new purchase order is generated, but with 144 units instead of 12
units. The quantity difference between the old SO quantity and the new
one is computed twice in the purchase order line UoM, in both
`_purchase_increase_ordered_qty` and `_purchase_service_prepare_line_values`:
https://github.com/odoo/odoo/blob/17.0/addons/sale_purchase/models/sale_order_line.py#L186

Solution:
The `quantity` parameter must be expressed in the SO line UoM, as
described in the documentation of the function `_purchase_service_prepare_line_values`.

https://github.com/odoo/odoo/blob/17.0/addons/sale_purchase/models/sale_order_line.py#L178

opw-6049106

Forward-Port-Of: odoo/odoo#258002
Forward-Port-Of: odoo/odoo#255478

## Overview
Accessing the Mobile Menu (QR ordering) or Self-Ordering interface crashes after installing `pos_blackbox_be` on SaaS-19.1. The interface fails to load due to a missing field in the POS data loading flow.

## Steps to Reproduce
1. Install `pos_blackbox_be`
2. Open POS  
3. Access the Mobile Menu (QR code) or Self-Ordering page  

## Current Behavior
- A traceback is raised  
- The interface does not load  

## Root Cause
The method `_load_pos_self_data_fields` returns the field:
iface_fiscal_data_module

However, from SaaS-19.1 this field was renamed to:
iot_fdm_be_id

This mismatch causes the POS self-ordering data loading to fail.

## Fix
Updated the returned field to match the new field name.

# Before
return fields + ['iface_fiscal_data_module']

# After
return fields + ['iot_fdm_be_id']

## Impact
- Restores proper loading of Mobile Menu (QR ordering)  
- Fixes Self-Ordering interface crash

opw-6044883  

## Reproduction Video
https://drive.google.com/file/d/1R5TYVIXvtts12YLF5iB4GKZirMZePoGr/view?usp=sharing

Currently, an error occurs if a user changes the product in a BoM, updates the manufacturing order (MO) based on that BoM, and then attempts to unbuild the order.

## Steps to replicate:
- Install Manufacturing without demo data
- Settings > Enable Variants
- Create the following products:
    - Car with (Red and Blue Color attributes)
    - Red Paint
- Create a BoM for Car and product variant set to Red Car and have Red paint as the component.
- Create and Confirm manufacturing order for Red Car
- Click on Bill of Material > Set Paint required to 2 > Save
- Set product variant in BoM to Blue and save again.
- Go back to MO > Update BoM > Produce All
- Unbuild qty 1 > Confirm

## Observed Behavior:
ZeroDivisionError: float division by zero

## Root cause:
This issue occurs because the Update BoM button remains visible on the Manufacturing Order (MO) even after the product has been changed.

The problem starts when a user initially updates the required paint quantity from 1 to 2. At that point, the function [1] marks the BoM as outdated for all linked MOs, which makes the Update BoM button appear. However, if the user later changes the product template or variant, the BoM is still considered outdated. This incorrectly allows the user to update the MO using a BoM that no longer matches the selected product.

**Why this causes a traceback when unbuilding?**

When the user clicks Update BoM, it triggers the `action_update_bom function` [2], which calls `_link_bom`. This process recomputes several fields to align the MO with the updated BoM. One of the methods triggered during this recomputation is `_compute_move_finished_ids` [3]. Since the production is already confirmed, the logic skips adding the production to `production_with_move_finished_ids_to_unlink_ids`, meaning no new finished moves are created for that updated product.

As a result, although the MO is updated, its finished product (`move_finished_ids.product_id`) still refers to the original product (for example, Red Car), instead of the newly selected one.

Later, when the user attempts to unbuild the product, the `action_unbuild` function [4] is executed, which calls `_generate_consume_moves` [5] During this step, the system tries to compute a factor that depends on `unbuild.mo_id.quantity_produced`.

However, because the finished moves still reference the old product and do not match the MO’s current product, the computed total becomes zero at [6] This leads to a division by zero error at [5], which ultimately causes the traceback.

[1]:
https://github.com/odoo/odoo/blob/444de5354dcd70e9160a985486317a8912d53a84/addons/mrp/models/mrp_bom.py#L432-L447 [2]:
https://github.com/odoo/odoo/blob/444de5354dcd70e9160a985486317a8912d53a84/addons/mrp/models/mrp_production.py#L1044-L1048 [3]:
https://github.com/odoo/odoo/blob/444de5354dcd70e9160a985486317a8912d53a84/addons/mrp/models/mrp_production.py#L771-L800 
[4]:
https://github.com/odoo/odoo/blob/97b60952d59a57aba12b048cb4da4f41d85d2ea2/addons/mrp/models/mrp_unbuild.py#L153-L164
[5]:
https://github.com/odoo/odoo/blob/444de5354dcd70e9160a985486317a8912d53a84/addons/mrp/models/mrp_unbuild.py#L225-L232 [6]:
https://github.com/odoo/odoo/blob/444de5354dcd70e9160a985486317a8912d53a84/addons/mrp/models/mrp_production.py#L641-L647

## Solution:
This change prevents users from updating a Bill of Materials (BoM) after the main product or its template has been modified, by ensuring the BoM is not marked as outdated.

This approach make sense because, once a manufacturing order (MO) is confirmed, all raw materials are physically reserved before production begins. While it makes sense to update BoM components in response to an Engineering Change Order (ECO) or last-minute specification changes, it does not make sense to allow changes to the final product itself on existing confirmed MOs. Doing so could lead to operational errors, since materials have already been procured and reserved for a specific product.

This fix ensures that if the product variant or product template is updated in the BoM, users cannot update the MO based on that BoM. This also prevents potential divide-by-zero errors when attempting to unbuild the product in the MO.

Reference commit which also suggests this behavior for the `Update BoM` button: [commit](https://github.com/odoo/odoo/commit/d7392829c769ef50456a7bc93d4482072b329463#:~:text=An%20exception%20however%3A%20if%20the%20MO%20is%20confirmed%20and%20the%20BoM%27s%20product%20was%0Achanged%2C%20the%20MO%20shouldn%27t%20have%20the%20%22Update%20BoM%22%20button%20displayed.%0AOtherwise%2C%20it%20would%20change%20the%20finished%20product%20of%20a%20confirmed%20MO.)

opw-6044754

Forward-Port-Of: odoo/odoo#260639
Forward-Port-Of: odoo/odoo#255981

In Mexico, the basic salary must be calculated based on the total calendar days of the period. This ensures that both worked days and non-working days (e.g. Sundays) contribute equally to the total payment. This calculation also applies to the daily schedule, as the proportional daily wage must be divided equivalently across the hours of the day.

Current behavior:
When an employee has an unpaid leave, the basic salary is incorrectly prorated using only the registered days/hours.
Example: For a monthly wage of 30,000 MXN in a month with 22 scheduled days (21 attendances + 1 unpaid leave), the implicit daily rate becomes 1,363.63 (30,000 / 22). This leads to an incorrect basic salary of 28,636.36 MXN for the days worked. This also happens with unpaid leave for x hours, e.g., for 2 hours, the unpaid leave is calculated as 2 hours * (30,000 / (22 days * 8 hours)) = 340.90 MXN, which is incorrect.

Expected behavior:
The basic salary should be derived from the full period (e.g., 30 days for a month, 15 for a bi-weekly period).
Example: For a 30,000 MXN wage, the daily rate should be 1,000 MXN (30,000 / 30 days). If there is 1 unpaid leave, the basic salary should be 29,000 MXN (29 days * 1,000 MXN), regardless of the number of scheduled working days in the calendar. For unpaid leaves by hours, e.g., for 2 hours, the unpaid leave should be calculated as 2 hours * (30,000 / (30 days * 8 hours)) = 250.00 MXN.

To achieve this, the calculation of the days in the `_get_worked_day_lines` is:
* Adjust worked days/hours for out-of-contract entries where necessary, ensuring that rest days(Sundays) are included in the count.
* Get all worked hours in the lines.
* Calculate the number of days to pay based on the total hours and the hours per day.

### Case: payslip does not cover the complete pay period
Current behavior:
If a payslip is created for a partial period, the total amount is the full period wage.

Expected behavior:
The total amount should be pro-rated based on the days of the period. For example, if a payslip is created for 25 days(with a monthly schedule pay), the total amount should be the daily salary multiplied by 25 days.

To achieve this, `_compute_amount` is updated to calculate the wage based on the `l10n_mx_daily_salary`.

Changes on tests:
* Add:
  * `test_monthly_payslip_with_partial_leave`, `test_partial_payslip`, `test_partial_payslip_new_hire_month_31_days` and `test_partial_payslip_new_hire_month_28_days`.
  * `test_hourly_payslip_by_attendance` to validate when `Work Entry Source` is set to "attendance".
* Update:
  * `test_hourly_payslip`, `test_monthly_payslip` and `test_partial_payslip_new_hire` to align with the new calculation.
  * Adjust payslips dates to match the `schedule_pay` in `test_regular_payslip_subsidy` and `test_weekly_schedule_pay_no_code`
  * Fix a one-day difference in `TestMxEdiHrPayrollCommon`(16 days instead of 15 days for a bi-weekly schedule), and update the corresponding CFDI values.
* Refactor tests and add new helpers.

### Error on [warning issues generation][1] and [`_compute_is_wrong_duration`][2]

The warning: `"The duration of the payslip is not accurate according to the structure type."` appears with these custom periods for Mexican Payroll, although the period is correct:
* `10_days`
* `14_days`
* `bi-weekly`

Steps to replicate:
* Install `l10n_mx_hr_payroll` module.
* Switch to "INNOVACION VALOR Y DESARROLLO SA SA" company.
* Go to Employees and open "Cesar Osbaldo Cruz Solorzano".
* Click on "Payroll" tab, change the "Pay Schedule" to any option listed above, for example "Bi-weekly".
* Go to Payroll > Payslips > Payslips and create a new pay run.
* Select Salary Structure 'Mexico: Regular Pay', Pay Schedule 'Bi-weekly' and the Period '01/01/2026 -> 01/15/2026'.
* Click on "Continue", select Cesar and click on "Select".
* It appears the warning issue.

Problem:
The warning is raised because of `slip.date_from + slip._get_schedule_timedelta() != slip.date_to` condition, because `_get_schedule_timedelta` function calls [`self._schedule_timedelta(schedule, self.date_from)`][3] without the `country_code` argument.
In the Mexican Payroll [_schedule_timedelta is overriden][4] but it is necessary to call it with the country code to use the custom periods; similar to how the [`date_end` is computed][5].

Solution:
Call `_get_schedule_timedelta` passing the `country_code`

[1]: https://github.com/odoo/enterprise/blob/1666ac87b6cb40e904210fecd159df3ac5b6b33a/hr_payroll/models/hr_payslip.py#L1367
[2]: https://github.com/odoo/enterprise/blob/1666ac87b6cb40e904210fecd159df3ac5b6b33a/hr_payroll/models/hr_payslip.py#L1454
[3]: https://github.com/odoo/enterprise/blob/1666ac87b6cb40e904210fecd159df3ac5b6b33a/hr_payroll/models/hr_payslip.py#L275
[4]: https://github.com/odoo/enterprise/blob/1666ac87b6cb40e904210fecd159df3ac5b6b33a/l10n_mx_hr_payroll/models/hr_payslip.py#L58
[5]: https://github.com/odoo/enterprise/blob/1666ac87b6cb40e904210fecd159df3ac5b6b33a/hr_payroll/models/hr_payslip_run.py#L211

target: 19.0
task-6073601

Forward-Port-Of: odoo/enterprise#112524

The `o_mail_wrapper_td` element in the `ThemeWrapper` template had a hardcoded `bg-white` class. The intent was for the wrapper background to default to white, but doing it this way meant the color didn't participate in the CSS variable system. Whenever a user set a custom Content Background color and a border-radius on a text block, the corners would reveal white underneath instead of the actual Content Background color.

Removed the `bg-white` class from the template and set white as the proper default for the `--wrapper-background-color` variable instead, so the wrapper is still white by default but correctly responds to the Content Background color picker.

Steps to reproduce:
1. Create a new Mailing
2. Set the Content Background color to something other than white
3. Add a Text block
4. Set a border-radius value on the block

=> white shows behind the rounded corners instead of the Content Background

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

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

Forward-Port-Of: odoo/odoo#247808

Steps to reproduce:
1- Install invoicing app
2- Add French language in the settings
3- Create a customer with language set as French
4- Create a product and define french translations of the name and the description in Sales tab
5- Create an invoice for that customer and choose the product you created
6- You will find the translated product name and description under the product name
7- Edit the description, save and preview the invoice
8- The invoice line will contain [Product Name EN] [Product Name FR] [Product Description FR]

Description of the issue:
When creating an invoice for a customer whose language differs from the user's account language, manually editing the product description on an invoice line causes the original product name to be prepended to the description. The same issue happens in a RFQ in Purchase.

Expected behaviour:
User can edit the product description in the invoice line and the output in the invoice should only be the translated name and description, without the original product name.

Why this happens?
1- When the product is selected in the invoice line, the label is loaded from _compute_name method in account_move_line, which holds the translated name and description.
2- After editing the description and escaping the field (clicking outside it), the parseLabel method is called, which prepends the original name to the label, making the invoice output as [original name] [translated name] [translated desc.]

Fix:
Use the product name returned in the label for trimming and concatenation to handle both original/translated text scenarios.

References:
original PR: #248401
partial revert: #254158

opw-5480494

Forward-Port-Of: odoo/odoo#256837

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

### Issue before this commit:
When handling many2many fields with a large number of records (e.g., 20k+), the client-side performance degraded significantly. In extreme cases, the browser became unresponsive or crashed when triggering onchange or compute logic.

### Steps to Reproduce:
Create a computed many2many field.
Add it to a form view (can be invisible).
Populate the related model with a large dataset (20k+ records). Trigger an onchange that recomputes the field.

### Cause of the Issue:
In _applyCommands (LINK case), the system checks for existing record IDs using Array.includes(), which has O(n) time complexity.
When handling thousands of records, repeated ID lookups using includes() result in O(n²) complexity.

### With This Commit:
Replaced Array.includes() with a Set (Set.has()), reducing lookup time to O(1). The set is updated incrementally as new IDs are added, improving overall complexity to O(n) and preventing UI freezes for large datasets.

opw-6122024

Forward-Port-Of: odoo/odoo#260993

# 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

When creating a procurement through mtso, if the product has a muti level bom with the same component at multiple levels, it will consider the available quantity multiple times.

Steps to reproduce:
-------------------
* Enable MTO and change supply method to: "Take From Stock, if unavailable, Trigger Another Rule"
* Create three products : final, semi, component
   - final: mtso, manufacture
   - semi: mtso, manufacture
   - component: mtso, buy, on hand quantity to 4
* Create a bom for final:
   - 10 components
   - 1 semi
* Create a bom for semi:
  - 10 components
* Create and confirm a MO for 1 "final"
-> Issue the purchase order is only for 12 components and not 16.

Observation:
-------------
When confirming our MO, it will create a manufacture procurement for the products.
The procurement will recursively create procurements and stock moves for each of its components.
https://github.com/odoo/odoo/blob/b0b8a102153eaa9231321524ec5140cc6d754502/addons/stock/models/stock_move.py#L1563-L1571
Since its a MTSO, it will first check the products if there is available products in stock (free_qty) and create the procurement for the missing quantity:
https://github.com/odoo/odoo/blob/b0b8a102153eaa9231321524ec5140cc6d754502/addons/stock/models/stock_move.py#L1646-L1647
https://github.com/odoo/odoo/blob/b0b8a102153eaa9231321524ec5140cc6d754502/addons/stock/models/stock_move.py#L1657-L1663
And each procurement, if it is of the manufacture type, will create corresponding procurements for their components.

Once all the procurements and stock moves have been created, the stock move will confirmed and assigned.
https://github.com/odoo/odoo/blob/942cbbbf243ff28f84fdaa40ed73b6572e0032a6/addons/stock/models/stock_move.py#L1627-L1629


-> The issue arise because the free_qty will only be updated when the stock moves are assigned which happen after all the procurement quantity are calculated for all the levels.

opw-5514788

Forward-Port-Of: odoo/odoo#253958

### Issue before this commit:
When sending a payment reminder email for a subscription using the email composer, the template  was not correctly populated with the expected dynamic values. In particular, fields such as the subscription closing date and the subscription code were missing.

### Steps to reproduce the issue:
1. Install subscription and go to that app
2. Open one subscription
3. Send message > Load template: "Subscription: Payment Reminder"
4. Sentence is incomplete: missing end date of the subscription

### Cause of the issue:
The issue was caused by the absence of a proper context injection when rendering the email template from the mail.compose.message wizard. The template relied on context variables like date_close, but these values were not being computed nor passed during manual email composition. Unlike automated flows, the composer did not provide the subscription-specific context required by the template.

### Reason to introduce the fix:
The fix makes the payment reminder and closing templates self-sufficient by replacing context-based values with fields and helper methods directly available on the subscription record. A dedicated method is introduced to compute the subscription close date consistently, so the templates render the expected values both in automated flows and when manually loaded from the email composer.

opw-6031613

Forward-Port-Of: odoo/enterprise#111801

**Problem:**
Changing the order of websites does not update which website is shown as the default when visiting from an incognito window (no domain match).

**Steps to reproduce:**
1. Create two websites with no domain set
2. Change their sequence order via the handle widget in the backend
3. Open an incognito window
4. The default website shown is still the old one

**Current behavior:**
The default website does not change after reordering.

**Expected behavior:**
The website with the lowest sequence should be served as the default.

**Cause of the issue:**
Commit d6f4af2790a0 replaced `models.Model` with `models.CachedModel` and removed the blanket `self.env.registry.clear_cache()` from the top of `write()`. CachedModel only auto-clears caches for fields listed in `_cached_data_fields`, but `sequence` is not in that list. As a result, `_get_current_website_id` (decorated with `@tools.ormcache`) keeps returning the stale cached website ID after a sequence change.

https://github.com/odoo/odoo/commit/d6f4af2790a0abacba6e616b00d999eddc30edc9#diff-5e92e473fa4d3da6db7ef727fb217dad51ef6c2383913edca73fe040a23e82c2L339-L341


**Fix:**
Restoring `clear_cache()` scoped to the existing sequence/company_id check ensures the ormcache is invalidated only when relevant fields change, rather than on every write as before.

opw-6102426

**Steps to Reproduce:**
1. Open Recruitments
2. Find a job position without a recruiter in the kanban view.
3. Clicking on the assign recruiter widget produces a traceback.

**Bug Cause:**
The ?unique= cache related parameter was added to the avatar image URL in the autoCompleteItem slot of KanbanMany2OneAvatarEmployeeField. This parameter relies on write_date being available on the autocomplete suggestion record. However, web_name_search only returns id and display_name, so write_date is undefined on autocomplete suggestion records, causing a crash when accessing autoCompleteItemScope.record.data.write_date.ts.

**Bug Solution:**
Remove the ?unique= parameter from the avatar image URL in the autoCompleteItem slot, reverting it to its original form. Cache is unnecessary for autocomplete suggestion avatars as they are only visible for the duration of the dropdown interaction.

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

Forward-Port-Of: odoo/odoo#261040