Have a view (e.g. list) with no real records but sample data. In the control panel, have a button that, when clicked, creates new records which match the current filter, i.e. which are displayed directly in the UI.

Before this commit, the new records were correctly displayed, but the sample data overlay (opacity) was still there.

The problem came from the fact that the sample data are automatically disabled when the view is reloaded **from above** (typically from the WithSearch component, when the user interacts with the search view). However, in the faulty scenario, the `load` function of the model is called directly by the view itself, so we don't go through WithSearch, and the code of model.js that ensures that we leave the sample mode.

We already faced that issue in pivot and graph, and we solved it locally. This commit fixes it globally, by creating a small override of model.load which leaves the sample mode.

task~5980226

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

Safari does not reliably set `KeyboardEvent.isComposing` during IME composition (e.g. Korean). As a result, the search value was processed too early and got cleared while composition was still in progress.

Interestingly, the issue could not be reproduced with the Japanese keyboard, which appeared to behave correctly. See [1].

This commit introduces a short delay before closing the autocomplete. On iOS, the IME temporarily triggers a Backspace event to remove the previously composed character before inserting the updated one. This Backspace incorrectly causes the autocomplete to close. With this change, we wait briefly (10ms) before closing it. If a new input event is received during that delay (corresponding to the newly composed character generated by the IME), the close action is cancelled.

This ensures that the autocomplete remains open while the IME composition process completes.

Steps to reproduce:
- Configure a Korean keyboard on an iPhone
- Open a Sale Order
- Focus the search bar
- Type a character, then type a second one to combine them
- The search input value gets reset

[1] #222151

opw-5448385

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

Steps to reproduce:
- Open the website shop page in edit mode.
- Drag and drop a block in the shop header dropzone.
- Save the page and re-enter edit mode.
- Check the shop header dropzone message.
=> The custom message is replaced by the default one.

Before this commit, `SetupEditorPlugin.cleanForSave()` removed
`data-editor-message` and `data-editor-message-default` on the saved
HTML clone, including custom messages defined in website templates.

This cleanup was originally introduced in `web_editor` in [1]. Since the
builder refactor in [2], website page saves now use the shared
`html_builder` save cleanup flow and wrongly inherited that behavior,
which introduced this regression in website.

This commit removes that cleanup from `html_builder`, as it does not
provide useful value in this save flow and drops custom dropzone
messages.

After this commit, custom dropzone messages are preserved after saving
website pages.

[1]: bab673488e185ddd7792aedecc3870663290fed3
[2]: 9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2

task-5921283

Forward-Port-Of: odoo/odoo#251579
Forward-Port-Of: odoo/odoo#250874

You cannot create a related field with a related field chain that has two or more fields with the same name in a row. When you click the relation icon for a field the wrong model will be displayed if the related model you are trying to show has a many2one with the same name as the field that was selected.

Steps to reproduce
1. Create two many2one fields with studio that have the same name, one of the fields must link to the model the other field is on. i.e. `model_a.x_studio_test(relation=model_b),
model_b.x_studio_test(relation=other_model)`.
2. Create a related field on model_a and click the related icon for the test field.
3. The popover will now be displaying the fields for other_model instead of model_b.

Cause:
This behavior was introduced by adding support for properties in this [pr](https://github.com/odoo/odoo/pull/189841). 

Solution:
Check if `fieldDef` is a property or not in order to decide what to pass to `loadPath`.

opw-ticket 5459944

Forward-Port-Of: odoo/odoo#249185

### Description of the issue/feature this PR addresses:
A regression in account_edi_xml_ubl_bis (_ubl_get_delivery_node_from_delivery_address) references invoice.invoice_date in the intracom delivery branch even when invoice is not set.
This method is also used in sale-order UBL export flows (for example during quotation PDF generation from mail.compose.message), where vals.get('invoice') can be None.
Blame points to regression introduction in commit 0bf8df7d0a096cf8fe984c42d331404d473eeb71 (FP from f6c5aed52e00e807c4879e4139b116f1bea8282e).

### Current behavior before PR:
When the flow reaches sale-order BIS3 export without an invoice in vals, Odoo crashes with:

AttributeError: 'NoneType' object has no attribute 'invoice_date'

This raises an RPC_ERROR and breaks the mail composer / send flow

### Desired behavior after PR is merged:
The intracom delivery-date override is only applied when invoice exists and has invoice_date.
If invoice is missing (sale-order export context), no crash occurs, the delivery node is still generated safely, and mail composer/report generation completes normally.
Invoice export behavior remains unchanged for valid invoice contexts.



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

Forward-Port-Of: odoo/odoo#250167

The rounding of time was not correct. I was always flooring, but before
the new duration the rounding was depending of the precision of the
duration. The rounding has been restored as before and put in
formatDuration.
formatFloatTime has been modified to use formatDuration and now take
the same options (specify the unit of time of the value).

The graph view and list view didn't extract the otpions from the fields
with widget. Now, they get the options and give them to the formatter.

The widget was showing the seconds by default, but it doesn't match with
the behavior of the DateTime widget. It has been changed and now the seconds
are shown only if the options 'showSeconds' is true and it's false by default.
The impacted views has been restored as before the original commit.

The options of float_time widget couldn't take falsy values, now it can.

an improvment has also been done: the popover on the float_time widget
doesn't show up if the input value and the formattedValue are the same.

followup of TASK-5347051

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

Steps to reproduce
===============
1. Open appointment of resource type
2. Create a new resource from resource tags.
3. Give the resource a name and save.
----> ValidationError will be shown.

Issue
=====
When creating the new resource from the appointment form view, the value for the `tz`
of the `appointment.resource` is `False`. Also, `tz` field is inherited from `resource.mixin`
and is a related field as `resource_id.tz`. Therefore, when creating the `appointment.resource`
with `tz` as `False` writes the related `resource.resource`'s `tz` field. As `tz` field is
required field for the `resource.resource` table, the `ValidationError` is raised.

Solution
=======
After this commit, we give the default value to the timezone with fallback to current
user's timezone or UTC which matches to the default value of `resource.resource`'s timezone field but
with a side-effect of overwriting resource's timezone if somehow `default_resource_id` is provided.

We also fix in parallel by making the timezone field `readonly` when invisible to avoid "saving" the
`False` value for the tz.

Task-5712786

## Issue
When creating and confirming an Upsell SO from a Subscription, the preview still shows the Sale Order as a "Quotation", which is inaccurate.

<img width="1330" height="296" alt="5489970" src="https://github.com/user-attachments/assets/cfff4c7a-fff7-4859-861b-c190dab9097d" />

## Steps to reproduce
1. Install *Subscription* (`sale_subscription`)
2. Create a Subscription S00001
    - Any Customer
    - Any Recurring Plan
    - Any Product
3. Create and confirm the invoice for the subscription S00001
4. On the subscription S, click Upsell and confirm the resulting Sale Order S00002
5. On the Sale Order S00002, click Preview
6. **The title of the Sale Order is "Quotation - S000002". In the sale.order list view, the Sale Order is shown as a Sales order, just like the initial Subscription.**

## Cause
The title shown in the preview is defined here:

https://github.com/odoo/enterprise/blob/a4e2c7c7d3aa50c8b57668c9ca73f523a31a5c41/sale_subscription/views/sale_subscription_portal_templates.xml#L187-L195

The initial subscription falls into the `if` condition, which only shows the name of the SO. The upsell sale order is not considered as a subscription, as explained and showed here:

https://github.com/odoo/enterprise/blob/6bfd057b3d17ce8b266aa6dbd88ffef70ca634aa/sale_subscription/models/sale_order.py#L193-L201

The word *"Quotation"* shown in the preview is the `sale_order.type_name`", computed here:

https://github.com/odoo/enterprise/blob/6bfd057b3d17ce8b266aa6dbd88ffef70ca634aa/sale_subscription/models/sale_order.py#L227-L237

The term "Quotation" was chosen in https://github.com/odoo/enterprise/commit/14e5cff65affa888f33d4008d10a32e6992d3a39.

## Fix
Before this commit, an upsell would always be named *"Quotation"*. With this commit, upsells are now added to the `other_orders` variable in `_compute_type_name` and follow the same logic as other SO:

https://github.com/odoo/odoo/blob/a3bf9264ca25ec11b0c9742e142d2404cac6d261/addons/sale/models/sale_order.py#L797-L803

<img width="1316" height="308" alt="5479900_2" src="https://github.com/user-attachments/assets/7cfeb578-2870-43a6-a48b-ba0898718641" />

## Alternative
An alternative to this fix would be to update the condition used to display the name of the subscription in the preview (cf. first code snippet). This would probably result in removing the `sale_order.is_subscription` from the condition, as it is the part of the condition that upsell SOs do not meet.

opw-5489970

Forward-Port-Of: odoo/enterprise#109268
Forward-Port-Of: odoo/enterprise#106767

### Steps to reproduce:

- Create a Stock User with access rights:
    - Sales: User: Own Documents Only
    - Inventory: User
- With your admin: Create and confirm a sale order for 1 x a consumable.
- With the  Stock User open try to open the delivery
#### > Access Error: Uh-oh! Looks like you have stumbled upon some top-secret records.

### Cause of the issue:

Sale users `Own Documents Only` are granted read access to the `sale.order` model which is restricted to the `sale.order`'s to which they are the designated sale person or no-one is due to this `ir.rule`: https://github.com/odoo/odoo/blob/d038b2c23b9f7c74d381e25276d00155bf89331e/addons/sale/security/ir_rules.xml#L44-L49 However, the read access of the sale order related to a stock move is required in order to compute its desciption:
https://github.com/odoo/odoo/blob/d038b2c23b9f7c74d381e25276d00155bf89331e/addons/sale_stock/models/stock.py#L26-L31 While this access is suppose to be provided:
https://github.com/odoo/odoo/blob/d038b2c23b9f7c74d381e25276d00155bf89331e/addons/sale_stock/security/ir.model.access.csv#L5 It is overriden by the `ir.rule`.

### Fix:

Since the `_compute_description` overrides rely on numerous independant models such as the `sale.order`, `purchase.order.line`, `product.supplierinfo`, `mrp.bom`, since the `picking_description` does not really carries sensitive informations and since parts of the computes already required to be put in `sudo` for similar reasons see 80c80505fabc4544e41f270169737218e47cad5a, it is preferable to compute the field in sudo rather than adding an `ir.rule` with true leaf on the `sale.order` model for the `stock.group_stock_user`.

opw-5929485

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

Forward-Port-Of: odoo/odoo#251471

**Problem:**
When using themes that define border-radius as unitless `0` (e.g., Anelusia theme) and attempting to modify the "Rounded Corners" value of any element through the website editor, the following error occurs: "Cannot convert 'px' units into '' units !"

**Steps to reproduce:**
1. Install and activate the Anelusia theme (or any theme with unitless border-radius: 0)
2. Open the website editor
3. Select any element (e.g., a table in the footer)
4. Try to change the "Rounded Corners" field to any non-zero value
5. Observe the error: "Uncaught Promise > Cannot convert 'px' units into '' units !"

**Current behavior:**
The website editor throws a JavaScript error and prevents changing rounded corners.

**Expected behavior:**
Users should be able to modify rounded corners values without errors, regardless of whether the theme uses unitless or unit-based zero values.

**Cause of the issue:**
Some themes define border-radius variables as unitless `0` (e.g., `$border-radius: 0`). When the website editor's areCssValuesEqual() function in utils_css.js compares the new value (e.g., "10px") with the existing computed value ("0" - unitless), it attempts to convert between units. The getNumericAndUnit() function extracts the unit from "0" as an empty string "", then convertValueToUnit() tries to convert "10px" to "" unit. Since there's no conversion defined for "px" to "" (empty unit), convertNumericToUnit() throws the error.

**Fix:**
Add a special case in areCssValuesEqual() to handle unitless zero values before attempting unit conversion. When the first value is unitless "0", we compare the numeric values directly using Number.EPSILON, avoiding the unit conversion entirely. This allows proper comparison between unitless "0" and values like "10px" or "0px" without errors, while maintaining correct equality checks (0 equals 0px, but 0 does not equal 10px).

opw-5412414

Forward-Port-Of: odoo/odoo#246335

**Issue 1:**

Steps to Reproduce

- Click on the More options button in the power buttons.
- The powerbox opens, but the editor loses focus and the button receives focus.

Description of the issue:

- After clicking the power button, the button becomes focused and the editor loses focus.

Solution

- When clicking the power button, after the command is executed in the click event, explicitly restore focus to the editable area so the editor remains focused.

**Issue 2:**

Steps to reproduce

- Click More options in the Power Buttons to open the powerbox.
- Start typing `heading`.

Description of the issue:

- The powerbox does not filter commands and continues to show all commands.

Cause:
- In `search_powerbox_plugin`, commands are filtered only when `shouldUpdate` is true.
- `shouldUpdate` is set only when the powerbox is opened through `search_powerbox_plugin`.
- Power Buttons open the powerbox via `powerbox_plugin`, so `shouldUpdate` remains false and filtering is not triggered.

Solution:
- Introduced `openSearchPowerbox` in `searchPowerboxPlugin`.
- Updated the implementation to use this method instead of `openPowerbox` in `search_powerbox_plugin`.
- Instead of opening the powerbox via `powerbox_plugin`, it is now opened via `search_powerbox_plugin`, ensuring `shouldUpdate` is set correctly and commands are filtered on keypress.

task-5485088

Forward-Port-Of: odoo/odoo#249844
Forward-Port-Of: odoo/odoo#244454

Follow-up of https://github.com/odoo/odoo/pull/250174

PR above attempts to solve race condition of the following test:

```
@mail/discuss/call/call/auto-focus participant video in one-to-one call in chat window
```

Where the meeting view may not have been considered as open and thus mistakenly trigger the speaker auto-focus feature.

However the test is still failing non-deterministically at the same step. While the previous fix sounds good in theory, this is insufficient. We couldn't reproduce the problem, but there are a few theories on what may cause the problem:

"Join Call" has side-effect to auto-focus speaker, which might mistakenly be triggered later in test if executing very fast. To make sure this doesn't happen, test now asserts playing of call-join sound, which happens close to the initial auto-focus of the speaker.

This commit also adds more intermediate assertions that should help awaiting proper time (thus avoiding race conditions) or help with further hints at what's wrong with this test:

- properly check video stream is off visually when other participant stops the camera feed
- click on active card should return to showing of 2 cards, before the other participant re-enables the camera feed in the meeting view
- make use of `card:has(video)` in earlier assertions, instead of `card video`, to more easily distinct which step is problematic. The last one is very likely the issue, therefore we keep the original `card video` as this is more likely to hit with the same runbot error entry, in case the problem is still ongoing.

Fixes runbot error 240554

This PR only applies changes requested during the backport as this is the version
of the original PR

--------

Backport of fixes added in odoo/odoo#238694

- banners don't work in emails because of inline conversion, and we don't need them
- video elements and iframes are also not supported, hence we can remove the plugin entirely
- the highlight inside the composer is redundant with the footer separator
- "edit" should not be a quick option for admins on other users' messages, instead reply is more appropriate
- signatures should be shown when composing replies and forwards as well
- images already embedded into the body of a message don't need to be shown as attachments as well
- images shown in the composer don't need to be big and legible by default, users can click on them as needed
- when the author has no email and there is no email from (log not on a fresh db for example), replying should be possible
- recipients should not be recomputed in the composer unless the user selected a template using specific recipients. This avoids picking a bunch of specific recipients only to lose them when picking a template.
- when sending a reply immediately without touching the body, the reply content should still be quoted

task-5013894

Forward-Port-Of: odoo/odoo#251062
Forward-Port-Of: odoo/odoo#239679