Currently, while generating an AI response, a `UserError` raised
due to a `RequestException` from the AI agent request at line [1]
is caught and logged as an error.

This happens because the exception is raised inside the except block of the
`/ai/generate_response` controller at line [2], including `UserError` raised
from line [1]. Since this controller is of type `http`, exceptions are not
propagated directly; instead, they are logged and the response is returned.

This commit ensures that an error is raised only if the exception is not
a `UserError`. By using `isinstance`, we prevent logging `UserErrors`,
allowing developers to focus on actual system errors rather than
expected (user-generated) errors, making debugging more effective.

[1]: https://github.com/odoo/enterprise/blob/d2dcdb892ac5dcc1af87d11f32abadbeb8029c3e/ai/utils/llm_api_service.py#L322
[2]: https://github.com/odoo/enterprise/blob/d2dcdb892ac5dcc1af87d11f32abadbeb8029c3e/ai/controllers/thread.py#L104

Sentry-5691330773

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

When we are at the appointment details page, and have the option allow_guests turned on, and go to the editor for translation, we encounter the issue.
Steps To Reproduce:
1. Create an appointment.
2. Go to the "Options" tab, and click on "Allow Guests".
3. Go to the web page for the appointment, select the data and time.
4. Now, on the details page, go to any other language than the default, and click on edit/translate.
5. The issue occurs.

The issue occurs when the regex tries to match the placeholder where the guests are added, which is enabled by the allow_guests. It contains strings  with newline characters. The regex fails to take into consideration for these newlines and breaks causing the issue to appear.

To fix the issue, we'll use regex to account for the new lines.
Also the fix adapts [this commit](https://github.com/odoo/odoo/commit/bc30d2592d4a7913eddf30bac8be2d94b6c22ad4) to work with the [website refactoring](https://github.com/odoo/odoo/commit/9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2)

opw-5412775

Forward-Port-Of: odoo/odoo#249195

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

Delayed translation (draft version from change of main language that
needs to be updated on each modified secondary language) on website
were added or disabled with:

- 2d08f97c0778469b409fca23f2be5f5a98ce3df8 (October 2023) in 17.0 added
  the delay translation feature
- 0e0a74f8c5fc9f45311e629a76608c6c986d635d (December 2023) in 17.0
  disabled the feature
- 03a85b13b2c46ef7174123d902e95d5103031c6c (September 2025) in 19.0
  enabled the feature again

Some website editor users may not expect the behavior (eg. changing a
background image, then needing to edit all secondary language so the
drafted change is saved).

For now we have not found a satisfying way to prevent delay translation
for simple use case that should not break translations: eg. removing a
snippet, changing attributes, ...

Because if we did special case, it would then become unexpected:

- will we need to update translations
- if there was a previous change that needed translation update, then we
  do a change that would not need translation update, what should we do

So this PR for now gives the option to create a ir.config_parameter:

- key: website.disable_delay_translations
- value: 1

That would disable the delay_translations feature for all websites if
the user doesn't want the feature.

opw-5187670
opw-5240423
opw-5250497
opw-5254832
opw-5344412
opw-5347408
opw-5419427
opw-5424761
opw-5481352
opw-5892371
opw-5931549

Forward-Port-Of: odoo/odoo#243490

Steps to produce:
---
- Install `website_sale` module.
- From the settings, enable `Prevent Sale of Zero-priced Products`.
- Create a product with a sale price of `0` and publish it.
- From the website, open the product page and add the product to the wishlist.
- Open the wishlist page.
- Enable the editor and change the product design to Chips, Cards, or Grid.

Issue:
---
- The Contact Us button is displayed incorrectly in some product designs.

Root cause:
---
- At [1], in the wishlist template, only the Contact Us text is displayed without the icon and label structure used by the Add to Cart button.
- Because of this, when different product designs are applied, the layout becomes inconsistent and the button appears misaligned.

Solution:
---
- Apply the same structure used for the Add to Cart button by adding the icon and label wrapper to the Contact Us button to ensure consistent styling across all product designs.

Backport of [commit]

[1]https://github.com/odoo/odoo/blob/e49536031f61b90212eb6f0d1a8a3e15927e723d/addons/website_sale_wishlist/views/website_sale_wishlist_template.xml#L353-L359

[commit]: https://github.com/odoo/odoo/commit/c697217ed0e009bd368617f25b5773c5d6ce3c92

Before:
---
<img width="261" height="358" alt="image" src="https://github.com/user-attachments/assets/cf3fe6de-5a7c-4a22-a908-09b8c121cdf4" />

After:
---
<img width="263" height="334" alt="image" src="https://github.com/user-attachments/assets/d44c41b9-0b48-41d0-992b-a506ba4428b6" />


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

Forward-Port-Of: odoo/odoo#252774

Steps to reproduce:
1. Enable "Display Extra Hours" in Attendance settings.
2. Assign an overtime ruleset to an employee.
3. Ensure the employee does not have the "Officer: Manage attendances" group.
4. Create an attendance that generates extra hours for this employee.
5. Log in as the employee and open the Employees app to view Extra Hours.

Issue:
An Access Error is raised because `get_overtime_data_by_employee` in
`hr_holidays_attendance/models/hr_employee.py` performs a `_read_group`
on `hr.attendance.overtime.line`. In 19.0, the only ACL for this model
grants access to `group_hr_attendance_officer`:
https://github.com/odoo/odoo/blob/95c73aa4dd7433f394799fdaaad57a84d750ec5a/addons/hr_attendance/security/ir.model.access.csv#L1-L11

Users with `group_hr_attendance_own_reader` (implied by `base.group_user`,
i.e. all internal users) have no read access to `hr.attendance.overtime.line`.

In later versions, this was already fixed by adding a read-only ACL for
`group_hr_attendance_own_reader` on this model:
https://github.com/odoo/odoo/blob/ad4a2ec11fea2058445e4003099af3a5caa1ef22/addons/hr_attendance/security/ir.model.access.csv#L13

This is why forward-ports are not needed.

Solution:
Add the missing `access_hr_attendance_overtime_line_own_reader` ACL to
grant read-only access to `group_hr_attendance_own_reader` on
`hr.attendance.overtime.line`, matching the approach used in later versions.
This is preferred over using `.sudo()` as it properly grants the intended
access right rather than bypassing security checks entirely.

opw-6055081

Forward-Port-Of: odoo/odoo#255576

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