steps to reproduce:
-------------------
1. Install sales
2. Enable Product Variants and Pricelists under Sales > Configuration
3. Open a product variant and create a pricelist rule
4. Save it

issue:
-----
The pricelist rules are not saved.

cause:
------
The field `pricelist_rule_ids` on `product.product` is a non-stored One2many. https://github.com/odoo/odoo/blob/b1041951d436b4b6adc90d8b8dd7b8c88cc69a46/addons/product/models/product_product.py#L62-L68 In the ORM, such fields are handled in the else part of [write_real()](https://github.com/odoo/odoo/blob/b1041951d436b4b6adc90d8b8dd7b8c88cc69a46/odoo/orm/fields_relational.py#L1033-L1049), Since this field is non-stored, it has no corresponding column in the database to persist changes. As a result, any updates made to it are lost after saving.

solution:
---------
Add an inverse method to make the field writable.

opw-5097909

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

Forward-Port-Of: odoo/odoo#229521

Some other test adds a fiscal position with tax mapping. This creates 2 problems

1. The new taxes have a tag, which means we evaluate the right hand of

https://github.com/odoo/enterprise/blob/8d3fe30c627eada1186c15480876fb2e8f7ddb59/delivery_shiprocket/models/shiprocket_request.py#L239

However, since l10n_in is not installed,

`tax.env.ref(f"l10n_in.tax_tag_{gst}gst", False)`

does not return anything (False is not a fallback)

https://github.com/odoo/odoo/blob/1e96a3d127e8f521d3027f7110026ae84e11ed5e/odoo/api.py#L588

So we end up looking for `None` in `tax_tag_ids`, which leads us to compare the `_name` properties, see

https://github.com/odoo/odoo/blob/1e96a3d127e8f521d3027f7110026ae84e11ed5e/odoo/models.py#L6545-L6558

2. The test added in 4d5df93 was assuming the default company 15% tax, which was not always true

Solution
-----

1. Provide a fallback for the `ref` lookup
2. Force a 15% tax in the test

-----
runbot-232692

Forward-Port-Of: odoo/enterprise#99027
Forward-Port-Of: odoo/enterprise#97998

Versions
--------
- 18.0+

Steps
-----
1. Have a product attribute with variant creation set to never;
2. have product using only this attribute, with only a single value;
3. open website editor on /shop;
4. enable add-to-cart button & save;
5. use button on the aforementioned product at least twice.

Issue
-----
Each time the product gets added, a new line is created.

Cause
-----
Because there's only a single value, the product configurator doesn't pop up by default when adding the product to the cart. Without the configurator pop-up, the `_cart_update` method doesn't receive any `no_variant_attribute_value_ids`, which are used find a matching line if the product template has any `no_variant` attribute.

Solution
--------
Instead of checking `product.product_tmpl._has_no_variant_attributes()`, to see if we should attempt to match `no_variant_attribute_value_ids`, check if the added product has any `no_variant` attributes that have more than one value or are optional (multi-checkbox). If not, a `no_variant` product behaves the same as a single-variant product.

opw-5093175
opw-5137351

Forward-Port-Of: odoo/odoo#234958
Forward-Port-Of: odoo/odoo#233452

Summary of the fixes for the Put/Pack in pack:
- Avoid an error when trying to click on 'Move a Pack' on an unsaved picking.
- Apply putaway rules at with multi-level packages, considering higher-level packages first.
- Consider higher-level packages when checking package routes.
- Updates the picking operation pdf.
- For pickings, no longer display the 'Packages' stat button if no package are set as destination. We keep it for batches however, as it's currently the only way to add entire packs into a batch.
- Be more lenient with the 'Remove' button for packages in a picking.
- Allow to select the right packages as destination in a picking.
- Change priority of move line when using 'Put in Pack', always prioritizing `picked` lines.
- Avoid `Unnamed` packages when creating a new package without a name from a list view.
- Display the parent packages in the 'Pick from' auto-complete.

For more detail about each fix, read the related commit.

Task-5116567

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

Steps to reproduce
------------------

Login to runbot, wait `odoo.http.SESSION_ROTATION_INTERVAL`s (3h) then access any page, then access any bundle using its id (not its `f'{name}-{id}') e.g. `/runbot/bundle/123`. Traceback: cannot use a closed cursor. It occurs when the system tries to save the session.

Traceback, explained
--------------------

1. The previous request session underwent a "soft rotation", its sid changed and it was marked "gc_previous_sessions".
2. The following request matches a route that is website & multilang, it is the case of the runbot bundle route.
3. The session was marked "gc_previous_sessions", it removes *now* the other sessions and removes the mark from the current one, this sets the current session dirty.
4. The request URL is not canonical, `_pre_dispatch` in `http_routing` abords with a redirection to `/runbot/bundle/18.0-123`.
5. The abortion (`werkzeug.exceptions.abort`) is an exception that bubbles up all the way up in the http stack, notably above `_serve_db` where `request.env.cr` is closed.
6. `odoo.http.root.__call__` ultimatelly processes the response received from `_pre_dispatch`: it calls `post_process` which call `_save_session` which sees that the current session is dirty: it attempts to save it.
7. Because there is a `session.uid`, we need to refresh the session token, for that we need an environment and a cursor.
8. Kaboom, the cursor was closed by `_serve_db`.

Problem
-------

When we set/delete items from the session, the changes are only saved in the session object in memory. The modified session is only written once, at the end of the request, if no error occured.

When we save the session, we gotta update the `session_token` value, this token is a SHA over the user's login information: active, email, password, ... and is verified upon loading the session in a future request. Should the user changes its password, a new token would be computed and all the sessions with the old token would become invalid. Should the user uses an old session, he would get redirected to /web/login.

Computing the `session_token` is mandatory when there's a `uid` inside the session, otherwise the session would be invalid. Computing it requires a valid cursor to fetch the user's active, email, password, ...

In our case, the (valid) response contained in `wekzeug.exception.abort` did bubble-up above `_serve_db`: `request.env.cr` is closed.

Solution
--------

Move the exception handling for `werkzeug.exceptions.abort` in both `_serve_nodb` and `_serve_db`. That it is in `_serve_db` makes it possible to call `_post_dispatch` with a cursor and environment that are still alive. This fixes the problem at hand.

With the above fix, comes two sanity things:

The `if session.uid and env` conditional is wrong, it must be only `if session.uid`. When there is a uid stored in the session, updating the `session_token` is mandatory. It MUST crash if `save()` is called for a session with a uid but with no environment.

The `_serve_db` method manages both the request's cursor and the `request.env` attribute. Everytime the cursor is updated (e.g. when changing from a read-only to a read+write one)

There’s no constraint preventing duplicate `ir.default` records. When setting a default using `self.env['ir.default'].set()`, it searches for an existing one, but if more than one match is found, accessing `default.json_value` raises a singleton error.

This fix makes sure the search only picks one record, avoiding that crash.

Before fix:
```py
self: res.users(1,)
>>> company = self.company_id
>>> company
res.company(1,)
>>> self.env['ir.default'].create({'field_id': 4540, 'company_id': company.id, 'json_value': 7})
ir.default(9,)
>>> self.env['ir.default'].set('res.partner', 'property_account_receivable_id', 7, company_id=company.id)
Traceback (most recent call last):
  File "/home/odoo/odoo/odoo/odoo/orm/models.py", line 5630, in ensure_one
    _id, = self._ids
    ^^^^
ValueError: too many values to unpack (expected 1)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<console>", line 1, in <module>
  File "/home/odoo/odoo/odoo/odoo/addons/base/models/ir_default.py", line 107, in set
    if default.json_value != json_value:
       ^^^^^^^^^^^^^^^^^^
  File "/home/odoo/odoo/odoo/odoo/orm/fields.py", line 1670, in __get__
    record.ensure_one()
  File "/home/odoo/odoo/odoo/odoo/orm/models.py", line 5633, in ensure_one
    raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: ir.default(4, 9)
```

After fix:
```py
self: res.users(1,)
>>> company = self.company_id
>>> company
res.company(1,)
>>> self.env['ir.default'].create({'field_id': 4540, 'company_id': company.id, 'json_value': 7})
ir.default(10,)
>>> self.env['ir.default'].set('res.partner', 'property_account_receivable_id', 7, company_id=company.id)
True
```

opw-5228419


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

Forward-Port-Of: odoo/odoo#234944
Forward-Port-Of: odoo/odoo#234893

Steps to reproduce the current behaviour:

- Update the DEMO user to be a website "restricted editor" and sales
"admin" who cannot bypass HTML field sanitization.

- As ADMIN, add a YouTube video to a product page > Save.

- As DEMO, try to update the content on the product page > You cannot
(a dialog informs you that you cannot edit the content because an admin
edited it previously).

Explanation:

Starting from [1], an HTML field can be flagged as `sanitize_overridable`
which allowed users with the `base.group_sanitize_override` group to
skip the HTML field sanitize process.

If such users added some content that is not considered "sanitize
friendly" (e.g. YouTube iframe), a restricted user won't be allowed to
add content in the fields, since the sanitizer will remove the original
content from the DOM.

For this case, the code from [2] added an implementation to consider the
field as none editable and warn the user once he tries to update it.

Implementation:

The goal of this commit it to fix the current limitation for video
upload that currently prevents non admin users to edit a website record
once an admin adds a video on it...

The idea of the fix is the following:

- We already have a technical fallback when uploading a video to save
the iframe `src` to an attribute: `data-oe-expression`.
- The public widget is now destroying the video iframes so they are
never saved in the DOM.
- A non-lazy code will build the iframes immediately on page load.
- The public widget can always create the iframes if they are not
already created (for compatibility).

[1]: https://github.com/odoo/odoo/commit/cf844e34dd0ce4830eb99fd0fa5b6b9cb58c867c
[2]: https://github.com/odoo/odoo/commit/cb80c15d3db49ede3c93171abcaa9064b88822c6

task-3757205

Forward-Port-Of: odoo/odoo#233792
Forward-Port-Of: odoo/odoo#175717