Description
-----------
When creating records with `vals` for HTML fields, there are two 'sanitization' operations happening:

1) Once in `convert_to_column`, when converting the `vals` for
   *database* insertion
2) Once post-insert in `convert_to_cache`, when converting the
   `vals` for insertion in the *cache* for the newly created records.

This redundancy has a negative performance impact when creating many records where new HTML fields are set, e.g., mass-mailing, as potentially large HTML documents are parsed and validated, often with external libraries.

To address this issue, this commit removes the insertion into *cache* of the HTML values for the newly created records. This removes the overhead of the second sanitization, speeding up the creation, and also helps with overall memory pressure, as we're not inserting large HTML fields into cache. The latter is particularly noticeable for long-running batch creation processes that do *not* commit intermediate results.

The downside of this patch is the potential *cache-miss* (and therefore the subsequent *query*) if the HTML field of the newly created records is read. This is unlikely in business code because intrinsically, an HTML field is often just a data 'blob' that has no logical usage. In the rare case where it needs to be read after creation, since the value in the database is already sanitized, re-sanitization is not necessary for insertion in the cache. Given these considerations, the trade-off seems reasonable to make.

Benchmark
---------
In a scenario for a marketing campaign with 1000 recipients, using a *mid-sized* email template and emulating a typical campaign, the results were:

| Method                        | Before   | After     | Speed up |
|-------------------------------|----------|-----------|----------|
| `_process_mass_mailing_queue` | 2.84 min | 1.55 min  | 1.8x     |
| `create`                      | 2.11 min | 50.23 sec | 2.5x     |

This represents roughly a *2x* performance improvement in processing an email campaign.

* more detailed benchmarks are available in the task's description

Reference
---------
task-4962646

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

**Step to reproduce**
- create a SO
- link 2+ invoices to it
- using studio, add invoice_ids to the SO Form
- trigger a onchange (ex. change the product from SOL)
- we receive a traceback

**Traceback:**
```ValueError: Expected singleton: account.move(<NewId origin=35>, <NewId origin=31>, <NewId origin=32>, <NewId origin=33>, <NewId origin=34>)```

**Issue:**
- from `onchange` triggers chain,`_compute_duplicated_ref_ids` is invoked calling `_fetch_duplicate_reference` for the related moves (invoice_ids) such that as they are in create/edit mode
- at this time `convert_to_write(moves[field_name], moves)` fails as moves has more than 1 record and `recordset[field]` is not valid syntax in such case
https://github.com/odoo/odoo/blob/3966753eb5a8534c8b5b8a16e626f5250c9013cf/addons/account/models/account_move.py#L1868-L1884

- hence, we receive valueError, expecting a singleton

**Fix;**
- we adapt the method to accept multiple moves which may be in
create/edit mode

opw-4959528

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

Currently, an error occurs when submitting the 'Send Email' form.

**Steps to Reproduce:**

 - Install the `website` and `web_studio` modules.
 - Go to `website` > Click on `Edit` > `Drag and drop form`.
 - Click the `form` and in `Actions` select the `more models`, and 
   select `outgoing mails(mail.mail)` model and `save`.
 - Fill out the form and `Submit`.

**Error:**
`KeyError: 'website_form_signature'`

**Cause:**
This error occurs after [this commit](https://github.com/odoo/odoo/commit/70fa5af872524ea271113851c050297ef50efa45), when submitting the "Send Email" 
form from the website. If the form is saved without entering the 
recipient's email (email_to). As a result, the `email_to` field is not 
present in the form. The `website_form_signature` is added from [1], 
but due to the condition at [2], the code at [1] is not executed. And when 
it is accessed at [3], KeyError is raised.

[1]: https://github.com/odoo/odoo/blob/82639728f2bcb4e7786f120de2aeba3f5fbab209/addons/website/tools.py#L252

[2]: https://github.com/odoo/odoo/blob/82639728f2bcb4e7786f120de2aeba3f5fbab209/addons/website/tools.py#L236

[3]: https://github.com/odoo/odoo/blob/82639728f2bcb4e7786f120de2aeba3f5fbab209/addons/website/controllers/form.py#L88

**Fix:**
This commit ensures that 'website_form_signature' is used if it is 
available in kwargs.

sentry-6746753251

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

Example Steps:
- Install `crm`
- Add a random field properties in a random form view
- Enable debug mode
- Open debug menu
- Select Data
- Traceback

```py
raise ValueError(f"Invalid field {field_name!r} on model {self._name!r}")
ValueError: Invalid field 'properties.xyz' on model 'x.y'
```

There are two causes for this problem.
First, we use orm.read to retrieve data from records, which does not directly handle sub-field properties. We only need to use `definition_property` (which contains the overall schema of the JSON field).

Second, when displaying the data, we use JSON.stringify with `replacer`:

```js
    get content() {
        const record = this.props.record;
        return JSON.stringify(record, Object.keys(record).sort(), 2);
    }
```
In this case, replace contains all the keys present in record, sorted. The problem is that the properties fields are themselves objects that contain the keys: `name`, `string`, `type`, `default`, `value`.

And giving an array to replace in `JSON.stringify` will filter the keys and keep only those that are whitelisted in it.
```js
// https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON/stringify
const foo = {
  foundation: “Mozilla”,
  model: “box”,
  week: 45,
  transport: “car”,
  month: 7,
};

JSON.stringify(foo, [“week”, “month”]);
// ‘{“week”:45,“month”:7}’, only keep ‘week’ and “month” properties
```

This will ignore the keys of the properties fields.

The fix is therefore to sort the object before stringifying it, without using replace.

Thanks to these two fixes, the data is displayed as expected, regardless of whether there are field properties or not.

opw-5017425

*=website

Target: 17.0 to saas-18.3

Issue: 
This issue applies to any block where multiple backgrounds are present (gradient + image).

Steps to Reproduce:
1. Drop a masonry snippet onto the page.
2. Select a block and change the background color to the gradient.
3. Add background image.
3. Change the image position from "Cover" to "Repeat Pattern."
4. Observe the traceback in the console.

Reason:
The issue occurred due to incorrect parsing of CSS background values when multiple background layers were applied (e.g., a gradient + image). When both are set, the element ends up with multiple background-related properties. Previously, In setValue method, Inside MultiUserValueWidget when value = "100px, 100px", the resulting values array was ['100px,', '100px'], which included an extra comma. This has now been corrected to properly handle such cases.

Other edge cases fixed:
1. Gradient was repeating along with the image.
2. Switching to parallax after repeat-pattern causes gradient to repeat.
3. Removing image kept repeat class, causing gradient to repeat.

Fix Summary:
1. We updated `selectStyle` and _computeWidgetState to correctly handle multi-layer background-size and repeat styles.
In selectStyle, we set the height and width values from options and apply them only to the image layer (not gradient), keeping the gradient layer unchanged.
In `_computeWidgetState`, we fetch the background-size from the target and, if multiple layers are present, return only the first one (image layer), since height and width options apply only to that. Now, setValue receives only single-layer values like
`100px 50px`, ensuring correct behavior.
Set background-size 'cover' to gradient which ensures only the image
repeats while the gradient remains fixed.
2. Remove `o_bg_img_opt_repeat` and reset background-size when
   - Image is removed.
   - Switching to parallax.
   
task-4577864

Forward-Port-Of: odoo/odoo#207757

As far as I can tell this can occur if the ws connection gets closed while we're in a `recv`: in that case `recv` will mark the connection as closed (`connected=False` and `sock=None`) and raise `WebSocketConnectionClosedException`, then any attempt to `send` will fail with `WebSocketConnectionClosedException`.

Here this likely is an issue because in `_receive` `WebSocketConnectionClosedException` goes through the generic exception handler, which sees that:

- it's not a `ConnectionResetError`
- the result is not set
- and the ws is not connected

So `_receive` just cancels the result and `return`s, and when whatever's waiting on a future finally times out it tries to cleanly shut down and hits a connection that's already closed.

Handle a connection closed in that context more properly:

- unset `ws` so we don't try to clean it up, as we know it's closed
- set the result as being in error
- cancel every future in order to immediately go to the tour failure step rather than wait for timeouts

Note that this will not really *fix* any error per se, because every time this happens it means the browser abruptly closed the WS connection (possibly straight up died), so this should mostly properly attribute the error so we can investigate it.

https://runbot.odoo.com/odoo/error/229793

Forward-Port-Of: odoo/odoo#224023

### Steps to reproduce:
	- Install Planning app
	- Create a portal user and an employee for this user
	- Create a shift for this user and Publish it
	- Go to the email that has been sent and click on View Your planning
	- Notice you are redirected to the portal dashboard home

### Cause:
Since this commit diff we removed the check if the user is having planning group https://github.com/odoo-dev/enterprise/commit/72afe1e14703f0a3eafd0cfaec10c67462db73ce#diff-293bc9f44292d19793981abbafbe2a55642d170bda5e3bf17d7654f7bffcbedaL62-L64 When getting the planning url that will be share in the email we don't check if the user is portal or not so we set the url with /odoo path and if a portal user is accessing a /odoo path it will redirect him to /my

https://github.com/odoo/odoo/blob/1acf4b2ce2bdad27e7d32d1227698968148a5935/addons/portal/controllers/web.py#L25-L26

### Fix:
We check if the user is portal we set the url with /planning path which will redirect the portal user to the correct planning view

opw-5045746

**Issue:**
Before this commit, the qty_delivered was wrong when using the Return button when a Picking was made in PoS

**Cause:**
The `_compute_qty_delivered` method in `pos_sale` adds `pos_line.qty` to the related `sale_line` each time it runs

When there is no PoS order, the method add 0 to the line, so the expected behavior work But when you have a PoS Picking, a quantity was added to `qty_delivered` each time the `rental.order.wizard` is used The issue also occured earlier when the `flush_all()` is called in `_process_order()`

**Fix:**
There is already a `_compute_qty_delivered` method in `pos_sale_stock_renting` that override the `qty_delivered` But it's restricted by `_are_rental_pickings_enabled()` That's not necessary because we don't use any `stock.picking` in the `_compute_qty_delivered` function, only `stock.move` so we removed that verification

To make the code working, we also need to extend the _get_outgoing_incoming_moves() results Because there were also block by a `_are_rental_pickings_enabled()` condition even if there is only moves here We need all the moves to calculate `qty_delivered` properly

**Steps to reproduce:**
- Create a New Product "Rental PoS" that Can be Rented
- Create and confirm a New Rental Order, with any customer and your product
- Open a PoS Session
- Click on Quotation/Order
- Choose the last Order and Settle the order
- Click on Yes (to confirm import to PoS)
- Click on Payment, select Cash and Pay
- Go in the Backend, and to your RO
- Click Return and Validate
- Before the fix, the Delivered should be 2.0

opw-4877019

Forward-Port-Of: odoo/enterprise#90510

An error occurs when a user attempts to mark a scheduled activity as done after the associated approval rule has been deleted.

**Steps to Reproduce:**
1) Install Sales and Web Studio modules.
2) Log in as Admin and use Studio to add an approval rule to the Sale Order’s Preview button.
>- Set Allowed Group to Access Rights.
>- Set Responsible User to Mitchell Admin.
3) In the Incognito Tab, login as Demo, open the same sale order and click on
   preview to create activity in chatter.
4) Delete the Approval Rule in the original tab.
5) Switch back to Demo and click Mark Done under Planned Activity in chatter.

**Error:**
`SyntaxError: syntax error at or near ')'`
 `LINE 1: SELECT id FROM studio_approval_rule WHERE id IN () FOR UPDAT. ^`

**Root Cause:**
The error occurs because the SQL query at [1] includes an empty tuple of rule IDs `(all_rule_ids)`. An empty `IN ()` clause in SQL results in a syntax error.

[1]- https://github.com/odoo/enterprise/blob/7ea45724e7689a0df11d20ace9c562788f5d19e3/web_studio/models/studio_approval.py#L366

**Solution:**
This commit avoids the error by ensuring that the SQL query only runs when `all_rule_ids` is not empty.

sentry-6306636466

Forward-Port-Of: odoo/enterprise#86982