**Current behavior before PR:**

- When dragging and dropping elements with attributes and classes, any non-whitelisted attributes and classes were removed during the `cleanForPaste` process. This caused structural issues and loss of formatting after the drop.

- When an image had a caption and only the image was selected and cut, the image was removed but the caption incorrectly remained

- When dragging and dropping an image without an active selection on the image, the image was not removed during the drop. This resulted in the image being duplicated, one at the original position and another at the drop location.

- When selecting an image with a caption and performing copy-paste, only the image was copied and pasted.

**Desired behavior after PR is merged:**

- An `application/vnd.odoo.odoo-editor` dataTransfer type is now set during `dragstart` for editor elements. As a result, we no longer need to clean the `dataTransfer` content during drop, preserving the original structure and preventing the loss of attributes and classes.

- Cutting an image that contains a caption now correctly removes both the image and its associated caption.

- The image is now selected on pointerdown event . As a result, when the image is dropped, deleteSelection correctly removes the original image before inserting the new one, preventing duplication.

-  Now, when an image with a caption is selected and copy-pasted, the entire image along with its caption is correctly copied and pasted.


task: 4914451

Forward-Port-Of: odoo/odoo#240788
Forward-Port-Of: odoo/odoo#217125

Issue
-----
After cancelling a MO created by a SO (MTO), user cannot reserve quantity from stock for the delivery picking. This happens for both MO & Reception as long as they are multi-step.

Steps to reproduce
-----
- Enable multi step routes
- Set WH to 3-step manufacturing
- Create a product
	- empty bom
	- MTO & manufacturing routes
	- 5 in stock
- Create a SO for the product
- Cancel the linked MO
- Open the delivery picking
- Click "Check Availability"

> The product is not getting reserved from stock

> The delivery picking is still "Waiting Another Operation"

Cause
-----
The problem happens in `action_cancel`

https://github.com/odoo/odoo/blob/3f7d79731fd5e5a751f7f1aeae63379c6211de5c/addons/stock/models/stock_move.py#L1995

In 1-step case, `move.propagate_cancel` is false so we go through

https://github.com/odoo/odoo/blob/3f7d79731fd5e5a751f7f1aeae63379c6211de5c/addons/stock/models/stock_move.py#L2017-L2021

where `move_dest_ids` is the move of the delivery picking.

This makes it so that, when we go to the delivery picking and do `action_assign` we go through the first condition while skipping the second of

https://github.com/odoo/odoo/blob/3f7d79731fd5e5a751f7f1aeae63379c6211de5c/addons/stock/models/stock_move.py#L1929-L1931

instead of going into the `else` part

https://github.com/odoo/odoo/blob/3f7d79731fd5e5a751f7f1aeae63379c6211de5c/addons/stock/models/stock_move.py#L1947-L1949

In 3-step, when we `action_cancel`, `move.propagate_cancel` so we go through

https://github.com/odoo/odoo/blob/3f7d79731fd5e5a751f7f1aeae63379c6211de5c/addons/stock/models/stock_move.py#L2009-L2014

which lacks the swap to MTS and unlink `move_dest_id` logic.

Solution
-----
We can re-use the logic of unlink and MTS swap to `move_dest_ids` that were not cancelled by

https://github.com/odoo/odoo/blob/0eb44aec8867e292f8258df02045efe7fbd3303f/addons/stock/models/stock_move.py#L2012

This also takes care of the problem of the status of the delivery picking being `waiting` instead of `confirmed` because it gets recomputed

https://github.com/odoo/odoo/blob/3f7d79731fd5e5a751f7f1aeae63379c6211de5c/addons/stock/models/stock_move.py#L754

and since it was set to MTS, it goes into the `else`part of

https://github.com/odoo/odoo/blob/3f7d79731fd5e5a751f7f1aeae63379c6211de5c/addons/stock/models/stock_move.py#L2202-L2216

-----
Ticket:
opw-5124380

Forward-Port-Of: odoo/odoo#241738
Forward-Port-Of: odoo/odoo#237890

* = hr_contract_salary

Steps to reproduce:
- Install 'hr', 'hr_payroll', 'hr_work_entry', and/or 'hr_contract_salary'.
- Log in as an HR Officer without payroll access.
- On an employee form:
  - Switch to the 'Salary Adjustments' tab.
  - Edit/save a record (tracking reads 'salary_offer_ids').
  - Click the 'Work Entries', 'History', or 'Offers' smart buttons.

Cause:
- HR Officers could still reach payroll-only data:
  - 'salary_offer_ids' (one2many to 'hr.contract.salary.offer') triggered
     tracking reads on a model restricted to HR Managers/Recuriters.
  - The 'Salary Adjustments' tab and offer buttons remained visible even when
     the user lacked payroll rights.
  - The payroll overrides changed 'contract_date_start' to
    'hr_payroll.group_hr_payroll_user', so the 'Work Entries'/'History' buttons
    show AccessErrors while the buttons stayed visible.

Fix:
- Restricted 'salary_offer_ids' to 'hr.group_hr_manager'.
- Made the 'Salary Adjustments' tab visible only to
 'hr_payroll.group_hr_payroll_user' and existing 'Offers' buttons stay for
  HR Managers.
- Added dedicated overrides giving 'Work Entries' and 'History' buttons the
 'hr_payroll.group_hr_payroll_user' group when payroll is installed.

Task - 5188997

Forward-Port-Of: odoo/enterprise#99234

To reproduce:
=============
- Create an accrual plan:
    - Carryover date: allocation
    - One level:
        - Accrues 2 days.
        - Accrual date: monthly on 1st of each month - Starts immediately on allocation start date - Carryover policy: all days carry over - Carried over days validity: 3 months.
- Create an allocation that uses the above accrual plan on 23/09/2025:
    - Starts on 01/07/2024

We should have 30 days in total with 24 expiring on 01/10/2025 but we only have 22 expiring on 01/10/2025.

Problem:
========
When `accrued_gain_time` of the accrual plan is 'start', in the `_process_accrual_plans` method, the property `expiring_days` is set when the first accrual still hasn't been added to the `number_of_days` (it is usually added at the [end of the loop](https://github.com/odoo/odoo/blob/18.0/addons/hr_holidays/models/hr_leave_allocation.py#L596)).

Solution:
=========
In the `_process_accrual_plans`, add the accrued days to the `number_of_days` before the `expiring_days` is set.

[opw-4963163](https://www.odoo.com/odoo/all-tasks/4963163)

Forward-Port-Of: odoo/odoo#240738
Forward-Port-Of: odoo/odoo#233424

## Steps To reproduce:
1. On a local environment, install **`website_sale_renting`** using `-i website_sale_renting`
2. During installation, the process reaches **`website_sale`**.
3. A traceback is raised while loading `website_sale/data/mail_template_data.xml`.

---
## Issue
* The installation fails during **`website_sale`** because the mail template calls `_get_rental_pricing_description()` on `sale.order.line`, but the method is not available at that stage.

---
## Cause:
* `_get_rental_pricing_description()` existed previously but was defined in **`website_sale_renting`**.
* A recent design PR- odoo/odoo#213186 introduced a `t-if="hasattr(combo_line, 'is_rental')"` guard in the `website_sale` mail template.
* Since `mail.template`'s body_html data is parsed as HTML, the template cannot be safely extended via XPath in other modules.
* Module installation order is: `sale → sale_renting → website_sale → website_sale_renting`
* When **`website_sale`** is installed:
  * `sale.order.line` already has the `is_rental` field (from `sale_renting`)
  * but `_get_rental_pricing_description()` is not yet present, as it is only loaded with `website_sale_renting`

This causes the guard to pass while the method call fails, leading to a traceback during installation.

---
## Solution:
* Move `_get_rental_pricing_description()` to the **`sale_renting`** module, alongside the `is_rental` field.
* This ensures the method is always available whenever rental logic is enabled and makes `website_sale` mail templates safe regardless of installation order.

opw-5454946
Affected Version-saas~19.1

Before this commit, the `resource_ids` field in `res.users` model was fetched in sudo due to the `resource_calendar_id` related field in `res.users` and so the user will get the resources of members in a helpdesk team from another company than the current one(s). The problem is since the current user does not have access to those resources due to the multi company rule, he will get a traceback when he will try to create a ticket from that helpdesk team if the assignement method is ramdom and a user with resource exists in another company.

This commit makes sure the resource_ids field in res.users is not fetched in sudo to correctly determine which user to set to the ticket when the current user tries to create a ticket.

Steps to reproduce the issue:
----------------------------
1. Install helpdesk module
2. Create a new company B
3. Create a new user with helpdesk user access right (or use Marc demo) and give the company B to that user
4. Select that new company created in step and go to helpdesk app.
5. Create an helpdesk team with auto-assignment set to "randomly" and set admin user as members in that helpdesk team
6. log in as the user created in step 3
7. make usre the company selected is the one created in step 2
8. create a ticket in the helpdesk team created in step 5

Expected behavior:
-----------------
The ticket should be created without any issue.

Actual behavior:
---------------
An access error is raised because the current user does not have access to the resource of admin user since it is not in the same company than the current one.

opw-5223717

Forward-Port-Of: odoo/enterprise#102910
Forward-Port-Of: odoo/enterprise#102859

Have a kanban view with progressbar and some records. Click on a progressbar to filter a column. Then open a record and come back. From that point, the data of the filtered kanban is in cache. Now, open a record again, and make a change in the form that will have an impact in the kanban (e.g. that will move a record from a column to another). Come back to the kanban view, which will instantly show the data from the cache, and that will be then updated once the rpc returns. At that point, the view is still correct, but the cache callback has already erased the groups information (in particular, the extraDomain of the filtered column). So, if you open a record and come back a last time, the view is no longer correct: the column that is supposed to be filtered displays all records.

Introduced by [1]

This commit basically reverts [1] and fixes the original issue differently. When we receive the result of a web_read_group, we can trust it and determine that a group for which we receive records (or groups) is open.

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

Task~5387553

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

A MemoryError can be thrown when running the scheduled action `_cron_recurring_create_invoice` on large databases. When there are lots of subscriptions, sale.orders and account.move.lines, the compute method overwrite `_get_invoiced` in the sale_subscription module can consume a lot of memory. The issue is mostly coming from the search on account.move.line. In case a lot of account.move.lines have a subscription_id, the search to get `all_subscription_ids` is going to return a lot of records. Then, accessing any field on this recordset will prefetch all the prefetchable fields, leading to a MemoryError.

This commit fixes that by manually fetching the fields we need on account_move_line. Since `subscription_move_lines` is not used anywhere else and `move_by_origin` only contains ids, the number of queries stays the same while the memory consumption plummets.

#### Benchmark

In a database with 236 000 account.move.line with a non-null subscription_id, running the schedule action with 5 subscriptions to invoice consumes at least 1.7GB (MemoryError raised). After this commit it consumes 191MB.

<img width="1918" height="943" alt="sale_subscription_before" src="https://github.com/user-attachments/assets/e868921f-e691-47c3-8474-edb9a1d22d0b" />

<img width="1920" height="949" alt="sale_subscription_after" src="https://github.com/user-attachments/assets/78e9fc31-4c5f-4369-8bd0-494ca2c693fd" />

Forward-Port-Of: odoo/enterprise#102364

Problem: When a manufactured product uses a component whose UoM is different from its reference UoM, for example the component’s UoM is dozens but units are used on the BoM line, updating the quantity to produce on the parent MO causes the child MO’s quantity to roduce to update incorrectly. This is because the new quantity to produce on the child MO is calculated with quantities in different UoMs.

Purpose: To ensure that the child MO’s quantity to produce updates correctly when the parent MO’s quantity to produce is updated. This is achieved by making sure the quantities that get added together are both the same UoM, in this case the product’s UoM.

Steps to Reproduce on Runbot:
1. Create product_a with the MTO route and UoM set to pack of 6.
2. Create a BoM for product_a that creates 1 pack of 6 products.
3. Create product_b.
4. Create a BoM for product_b that creates 1 unit and uses 3 units of product_a. Make sure the component line shows 3 units instead of 0.5 pack of 6.
5. Create a manufacturing order for 1 unit of product_b and confirm it.
6. There should be a child MO for 0.5 pack of 6 of product_a.
7. On the parent MO update the production quantity to 2 units.
8. Observe that the child MO is now for 3.5 pack of 6 instead of 1 pack of 6.

opw-5414085

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

Forward-Port-Of: odoo/odoo#241692