Currently, when the user creates a task for a customer with a discount pricelist, the discount is applied twice for the service.

<h2>Steps to produce:</h2>

* Install `industry_fsm_sale` and enable `Discounts` and `Pricelists` in settings.
* Create a pricelist with a price rule of type discount that applies 10 percent discount to every product.
* Go to Customers > Acme Corporation > Sales & Purchase and set the pricelist.
* Go to Field Service > Create a Task, and set `Customer` to Acme Corporation.
* Add a timesheet with Time Spent 1 > Mark the task as Done > Sale Order

<h2>Observed behavior:</h2>

The discount is applied twice to the product on SO:

**Product**: Service on Timesheets
**Unit Price**: `$40` (excluding tax)

**First discount:**
The 10 percent discount on the unit price of the product.
Product unit price is set from  `$40 -> $36
`

**Second discount:**
The 10 percent discount on the SO line itself.
`$36 -> $32.4
`

The untaxed amount is: `$32.40` which should be `$36.00`

<h2>Root cause:</h2>
This happens because, at line [1], the unit price is already set to the final price from the pricelist when the sale order line is created. Since discounts are enabled, [2] applies an additional discount to that same price, causing the discount to be applied twice.

<h2>Solution:</h2>

When creating the sales order:
* **Discount setting is on:** use list price so the discount is applied from the sales order.
* **Discount setting is off:** set the product unit price to the discounted price.

[1]-
https://github.com/odoo/enterprise/blob/224d2453cc975a3e333825370beaf30d27d89f10/industry_fsm_sale/models/project_task.py#L658 
[2]-
https://github.com/odoo/odoo/blob/76717e588bfd012b42e859bfc829257d899c6165/addons/sale/models/sale_order_line.py#L788

opw-5432088

Forward-Port-Of: odoo/enterprise#112761
Forward-Port-Of: odoo/enterprise#103950

Scenario:

- add the dynamic Products snippet on top of page and save
- go to the website with browser address bar that change height when
  going when going down in the page (hide or change size of it that is
  changing the viewport size)
- scroll all the way up and down in the page

Result: there is some jump that happen when the browser interface change
size when scrolling down or up.

Cause:

When going down the page, the viewport size changes (because the address
bar gets bigger / smaller). This causes the dynamic snippet to be
re-rendered.

Since February 2026 commit 2e5bd409581ddaab28084c42ab51b50b494f4876 to
optimize performance, product blocks are only rendered when the are in
the viewport (may depends on browser) with "content-visibility: auto".

The combination of those two things, causes that if you scroll down, the
widget is re-rendeded in owl, but it is only rendered in the page once
you scroll in the viewport so the scroll jump up or down with the
products snippet being rendered (going from 0 to eg. 300px when
scrolling into viewport) or not being rendered (going from eg 300px to
0 when scrolling and the widget not being in viewport).

Fix: remove the "content-visibility: auto" when we are in the dynamic
"Products" snippet, it was intended for the shop view and not for the
case where product block can be re-rendered outside of viewport.

opw-6005340

Note: this is mainly happening on mobile browser (eg. safari on iOS) because of the viewport resize when scrolling, but this can somehow be reproduced on chrome desktop:

- scroll below a "Products" snippet, change browser window size manually

=> the should be a jump of the content up

- scroll up to go back to the product snippet

=> the content of product snippet should appear all at once when the 0 pixel heigh get in the viewport

Forward-Port-Of: odoo/odoo#256815

Moving a section around in sale order lines when there is a line that can be abandoned throws an error

Steps to reproduce:
1. Install Sales app
2. Go to Sales and create a new quotation
3. Add any product, then add a section: enter any name for the section and then immediately press Enter (it should create an empty product line)
4. Without leaving edit mode, drag and drop the section at the top of the sale order lines (the empty product line should still be there)
5. An error is thrown

The same issue can be reproduced by moving a section down:
3b. Add any product, then add a section: move it to the top of the order lines then enter any name for the section and immediately press Enter (it should create an empty product line)
4b. Without leaving edit mode, drag and drop the section just between the product line and the empty product line

Issue:
`sortDrop` calls `leaveEditMode` at
https://github.com/odoo/odoo/blob/e906eb23d698061f146ba67aae420eb7bb5e8a68/addons/web/static/src/views/list/list_renderer.js#L2242 which removes order lines that can be abandoned
https://github.com/odoo/odoo/blob/e906eb23d698061f146ba67aae420eb7bb5e8a68/addons/web/static/src/model/relational_model/static_list.js#L379-L381 This can remove records from the recordMap generated before calling `super.sortDrop` in
https://github.com/odoo/odoo/blob/e906eb23d698061f146ba67aae420eb7bb5e8a68/addons/sale_management/static/src/fields/sale_order_line_field/sale_order_line_field.js#L175-L182 so we end up calling `_handleQuantityAdjustment` with a recordMap that contains record ids that have been deleted, throwing an error when we try to access the deleted record

Solution:
Call `leaveEditMode` before computing recordMap in order to remove the records that can be abandoned. This prevents `this.props.list.records` from being different when we generate recordMap and when we call
`_handleQuantityAdjustment`.
We also need to set the record being moved as dirty. This prevents the record from being abandoned when `leaveEditMode` is called.

opw-6022538

Forward-Port-Of: odoo/odoo#256662

Problem:
The toolbar does not open when using Cmd+Shift+Arrow to select text on macOS.

Cause:
On macOS, when the Cmd key is held down, the `keyup` event is never fired for other keys. The toolbar relies on `keyup` for Arrow keys to re-enable `onSelectionChangeActive` and trigger the toolbar update, so it never opens.

See section ("Issue 3 - keyup event put on hold for other keys"): https://web.archive.org/web/20160304022453/http://bitspushedaround.com/on-a-few-things-you-may-not-know-about-the-hellish-command-key-and-javascript-events/

Solution:
Track when an Arrow key is pressed while Cmd is held (`pendingArrowKey`) and use a `selectionchange` listener as a fallback to re-enable the toolbar. The `selectionchange` event fires reliably on macOS even when `keyup` is suppressed. A `isMouseDown` guard ensures the listener does not interfere with the existing mousedown/mouseup flow.

Steps to reproduce:
1- Type some text
2- Use Cmd+Shift+Arrow (left or right) to select text 3- Observe the toolbar does not appear

task-6013408

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

Forward-Port-Of: odoo/odoo#257166
Forward-Port-Of: odoo/odoo#253293

**Steps to reproduce**
- Install `pos_hr` with demo data
- Open Settings > Manage Users
- Validation Error: A user cannot be linked to multiple employees in the same company

**Cause**
`employee_id` for the current user was computed as False here: https://github.com/odoo/odoo/blob/361aa8505506f9686b1cdb244ba1723ee3f06f7b/addons/pos_hr/models/pos_config.py#L27 Despite an employee already existing, which led to the error here: https://github.com/odoo/odoo/blob/361aa8505506f9686b1cdb244ba1723ee3f06f7b/addons/pos_hr/models/pos_config.py#L30

This exposes an issue with `_compute_company_employee`:
- the compute is called a first time on multiple users, including the current user, in a non-sudo environment
- the `employee_id` field for the current user is accessed in a sudo environment

The problem comes from the search in non-sudo, which uses an `ir.rule` that evaluates `user.employee_id` in sudo while we are computing `user.employee_id`.

**Fix**
We avoid the cache issue by always performing the search in sudo.

opw-6046297

Issue Before This Commit:
=======================
When RFQs are sent using the `Send by mail` action from the list view, their state remains draft instead of being updated to sent, so users see them as not sent even though they were already emailed and have to send them again using the `Send RFQ` button from the form view to mark rfq as sent, which is inconsistent with the form view behavior and confusing for users.

Steps to Reproduce:
=======================
- Install the `Purchase` app.
- Go to Purchase and select multiple RFQs in the list view.
- Click `Send by mail` from the actions menu.
- Select the RFQ email template and send the email.
- Observe that the RFQs remain in state RFQ instead of being set to RFQ Sent, unlike when using the `Send RFQ` button in the form view.

Cause of the issue:
=======================
The `Send by mail` action in the list view does not apply the same state update logic as the `Send RFQ` button from the form view, where the RFQ state is updated when the email is posted on the purchase order. As a result, when emails are sent from the list view (mass mailing flow), the RFQ state is not updated

After This Commit:
=======================
When emails are sent using Send by mail, purchase orders in state draft are updated to sent in `_message_mail_after_hook` after the email is sent. This keeps the list view flow consistent with the form view behavior and prevents users from having to resend RFQs just to update the state.

TaskID-5443248

Steps to reproduce:
-------------------
1. Install Timesheets and Time Off.
2. Create a new Time Off type with duration type "Half Day"
(disable "Require allocation" to skip allocations).
3. Enable "Timesheets" in Timesheets > Configuration.
4. Ensure the employee is configured with a "Flexible" working schedule.
5. Create a multi-day Time Off request (2 days) using this type and approve it.
6. Check the timesheet entries for the employee.

Issue:
------
When a multi-day time off request is submitted for a "Half Day" time off type,
the system fails to generate individual daily timesheet entries. Instead, it generates
a single timesheet entry with a duration calculated as calendar.hours_per_day / 2,
regardless of the actual number of days requested.

(e.g., if hours_per_day is 8, it generates one entry of 4 hours for a 2-day leave),

Cause:
------
After this commit 9512832, multi-day requests were allowed for time off types
where the **request_unit** is "half day" or "hours". However, the logic in `_generate_timesheets`
for flexible calendars was not updated to account for this.

Previously, `request_unit_half` was computed as:
https://github.com/odoo/odoo/blob/feb3cd520d7a736996621f7765184edca6ac390c/addons/hr_holidays/models/hr_leave.py#L319-L323

But now, the condition is:
https://github.com/odoo/odoo/blob/14ccd1f54e21c07ac68593c8dec7682371f8663c/addons/hr_holidays/models/hr_leave.py#L467-L470

Since `request_unit_half` now stays **True** regardless of the request duration
(as long as the Type is 'half_day'), the following condition in `_generate_timesheets`:
https://github.com/odoo/odoo/blob/14ccd1f54e21c07ac68593c8dec7682371f8663c/addons/project_timesheet_holidays/models/hr_leave.py#L39 always evaluates to **True**. This traps multi-day requests in the
"single-day" logic, preventing the code from reaching `_list_work_time_per_day`.

Solution:
---------
Update the condition to strictly check if the request is a single day before applying
the simplified single-entry logic. If the request spans multiple days, it will now
correctly fall into the else block, utilizing `_list_work_time_per_day` to generate
one timesheet entry per day of the leave.

opw-5715197



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

Forward-Port-Of: odoo/odoo#248605