Commit [1] introduced default images changes for the website library. The problem is that the ir.attachment definitions are in a non-updatable environment by mistake (apparently since forever)... so they are not updated after update/upgrade.

This commit moves the definitions to its own updatable file, in 17.0 and above only (ignoring potential other changes that were made in 15.0/16.0 at the time but apparently led to no issue). But this is not enough: upgraded users will still have those ir.attachment records marked as non updatable and will thus not be updated. Meaning that the ir.attachment record will still reference path to images that do not exist anymore (since [1]) and thus not display anything in related snippets, or worse: crash on some non-robust-to-404-images options (This will be made more robust in another update).

Note that, at the moment, we cannot solve this issue by making the /web/image route not return a 404 but a placeholder image in that case, for technical reasons (even though it would be consistent as this is what is done if you try to reach `/web/image/something_with_a_typo`).

It would also be annoying to solve this problem by adding a migration script inside the Odoo repo itself:
- It would only work if upgraded users do a -u again (unlikely).
- That would mean an upgrade script rotting in the main repo forever.

Instead, this commit chose to restore the removed images so that upgraded users will be able to use the outdated paths. In master, an upgrade script will be made (in the upgrade repo) to properly update all those attachment records and be able to finally remove those outdated images. Note that this may also be fixed without upgrade script if non-updatable records whose XML declaration is moved out a non-updatable area become updatable (under discussion with the framework team... we will see when this lands in master).

Steps to reproduce:
- Install a 16.0 with the website module
- Upgrade to 17.0
- Drag a "Blockquote" snippet on a page => Crash and the image is missing (in the DOM but invisible and
   impossible to edit). Note that the crash itself will also be fixed by
   the later update that will be done to make editor options more robust
   to 404 images.

[1]: https://github.com/odoo/odoo/commit/a4377bfa85b19be29a430573e0f42fff4da52757

opw-3693055
opw-3723895
opw-3744257
opw-3747348
opw-3749764
...

Forward-Port-Of: odoo/odoo#155015

Part 1: _search_is_member
-------------------------

Separate query to fetch candidate channels because the sub-select that
`_search` would generate leads psql query plan to take bad decisions.
When candidate ids are explicitly given it doesn't need to make
(incorrect) guess, at the cost of one extra but fast query.

It is expected to return hundreds of channels, a thousand at most, which
is acceptable.

A "join" would be ideal, but the ORM is currently not able to generate
it from the domain.

`sudo` is added as well because the rules for the member don't need to
be checked as no information is leaked.

Part 2: clean rules
-------------------

The rule for reading "self" is included in the rule for reading other
members. It can be disabled for "read" to avoid duplicate.
It also checked is_member again, but is_self necessarily implies it.

Part 3: clean tests
-------------------

The opportunity is taken to fix the tests. The tests where considering
as "access error" when there was an assert error inside the test (for
example not finding the channel or the member), but those needed to be
considered as failure regardless of expected outcome of access check.
Extra mute loggers are added to clean the test output.

Forward-Port-Of: odoo/odoo#153697

Currently, when adding a product to a quotation with the catalog, no warning message will appear when adding a poduct that has a warning or blocking message.

Steps to reproduce:
-------------------
* Go to **Sales** app -> Configuration -> Settings
* Enable **Sale Warnings**
* Go to **Products** -> Products
* Create a new product
* Under **Sales** tab:
  * For warning, select either warning or blocking message
  * Write a message
* Go to **Orders** -> Quotations
* Create a new quotation
* Select the **Catalog** to add products
* Add the newly created product

Why the fix:
------------
The first version of this fix was a python exclusive change. It was a bit hacky; it was raising an error when the product had a blocking warning and sending a message on the bus when the product had a non-blocking warning.

The second version was changing the return value of `_update_order_line_info` to return the price and the warning if any. The warning was shown inside JS with `_updateQuantity`. This change was not good for a stable verion as it was changing the signature of a public method.

This fix automatically changes the data that is loaded to the catalog. It adds the warning message if any and changes the `readOnly` field accordingly.

Warning/blocking messages will be automatically displayed in the catalog, on the product informations. Products with blocking messages will me marked as readonly to avoid being able to add the product to the sale order (this is the original behavior for blocking messages).

Regarding the field `readOnly` and ẁarning`:
* We can't write `res[product.id]['readOnly'] = product.sale_line_warn == "block"' because readOnly is set to True by default if the sale order is cancelled and doing this would overide that value later. See:
https://github.com/odoo/odoo/blob/21c25a7ccd0ba2d6574ddbcfbcf50dbbc03a1e6c/addons/product/models/product_catalog_mixin.py#L97-L99

* We're also sending the warning only if there is one because of this:
```python
	<span t-elif="props.readOnly" class="my-2 pt-3 border-top" t-out="props.warning">
            You can't edit this product in the catalog.
        </span>
```
Because in the case where readOnly is True for another reason than the product having a blocking warning, the initial message will be displyed.

Since the module purchase also uses the warning on products, this fix is extended to include it.

opw-3631511

Forward-Port-Of: odoo/odoo#149155

**Current behavior:**
Creating a promo type loyalty program and editing the
'products' field in the 'Among' section of the rule created by
default at the bottom of the form view before saving the
program will cause the products selected in this field to be
cleared upon saving the program.

**Expected behavior:**
Filling out this field of the default rule before saving the
overarching loyalty program should result in the same behavior
as doing so after saving the program. That is, the field should
save the user's input.

**Steps to reproduce:**
1. Create a new loyalty program in the Discount & Loyalty tab

2. Give it a name and, before saving the program, edit the
     'Products' field of the default rule that is created at
     the bottom of the form to have at least one value

3. Now save the program and observe that the 'Products' field
     has been cleared of the previously selected values

**Cause of the issue:**
In the form view for the loyalty.program there are two
instances of the field trigger_product_ids which are set to be
invisible unless creating a specific program type. This field
is set to be related to rule_ids.product_ids in its definition
within the loyalty.program class definition. Thus, when the
user saves the program and rule concurrently, the empty
trigger_product_ids field overwrites the product_ids field
and whatever the user had populated it with is cleared.

The reason it only happens to the default rule and not ones
which are manually added before saving the program is because
in the traverse_related() method in fields.py, only the first
record of the related field is returned to be modified. In this
case, it means only the first rule's product_ids field is
overwritten.

**Fix:**
Overwrite the create() method in program.loyalty and check if
the program being created is of type 'gift_card' or 'ewallet'
then, if so, delete the trigger_product_ids key,val from the
dictionary so it will not later override the products specified
in the loyalty rule.

opw-3669953

Forward-Port-Of: odoo/odoo#150418

Steps to reproduce:
-------------------
- create an accrual plan;
- create an accrual level;
- save;
- create a second accrual level;
- save the form;

Issue:
------
We trigger an error with an invalid `added_value_type` field.

Cause:
------
The `added_value_type` is a compute stored field without inverse. As it is not inversible, this field will be readonly by default [^1].

When the dialog window is opened, we trigger a specific logic which will trigger an onchange [^2].

During this onchange, we work with a virtual record from the `hr.leave.accrual.level` model (the one corresponding to the first level) which has an origin. Unfortunately, we are using the cached value for the virtual record, i.e. `None`. The latter will have been set as if it is a record without origin.

As the `added_value_type` field is readonly on the dialog form view, we have to save the record with this value.
Since this field is required, the error occurs.

Solution:
---------
In order to use the value on the original record,
the field must be forced with `readonly=False`.

Note:
-----
Commit which introduced the issue: 0a9e83dfd81300fd1204693cf6d4dca2bab40b2c The fix allows you not to use `_origin`
(which normally shouldn't be used in this case).

[^1]: https://github.com/odoo/odoo/blob/e89ed59269974f148c2285446dcd60e871df1a01/odoo/fields.py#L451
[^2]: https://github.com/odoo/odoo/blob/25cda065dccaae5edd861114c29157c7abb68533/addons/web/static/src/model/relational_model/static_list.js#L194-L299

opw-3745463

Forward-Port-Of: odoo/odoo#155033

### Steps to reproduce

* install `l10n_sa_edi`
* switch to a Saudi company
* deactivate the "EDI : Perform web services operations" scheduled action. (this will help ease the reproduction process)
* create and post two invoices for a partner that's an individual (not a company)
* manually run that scheduled action.

You should be met with a traceback.

### Cause

When a ZATCA document is submitted, the system performs several operations, two of which are important for this issue:
1. Generating a signature (`l10n_sa_invoice_signature`)
2. Using this signature to generate a QR code (`l10n_sa_qr_code_str`)

The QR code generation relies on the assumption that the signature (`l10n_sa_invoice_signature`) already exists, which is a reasonable expectation as the signature is typically created prior to the QR code.

However, complications arise when multiple documents are submitted simultaneously in a batch process. During batch processing, each document in the batch undergoes the same two operations mentioned above. The issue emerges due to the behavior of non-stored computed fields.

In Odoo, computed fields are evaluated in batches, meaning that if you access a computed field for one record, Odoo may also compute the same field for other records fetched in the same operation. For example, if you have two records, `A` and `B` such that `B.id in A._prefetch_ids`, and you access a computed field on `A`, Odoo will also compute this field for `B` at the same time.

This behavior leads to an issue when submitting two documents (`D1` and `D2`) together. The system will generate a signature and then compute the QR code for `D1`. However, when computing the QR code for `D1`, it inadvertently attempts to also compute the QR code for `D2` due to the batch computation behavior. Since `D2`'s signature has not yet been generated at this point, this results in an error.


opw-3696146

Forward-Port-Of: odoo/odoo#153810

Current behaviour:
---
When an employee places an event on a certain day
starting at 00:15 to 18:00 on a brussels TZ,
the event is stored on the UTC TZ, so starting
the day before at 23:15 to 17:00.
This behavior shows the employee as available.

Expected behaviour:
---
The employee should not be available even
if the event start on another day.

Steps to reproduce:
---
1. Employee and db has a Brussels TZ
2. Go to Calendar
3. Add an event when employee is available
4. Event starts at 00:15 and ends at 18:00
5. Go to website > Appointment
6. Select Mitchell Admin
7. Look at the date, should be unavailable
8. => Still available

Cause of the issue:
---
https://github.com/odoo/enterprise/blob/d6135811316837d6523e59163739fc9b954be2e6/appointment/models/calendar_appointment_type.py#L295 
If the event starts on another day than the slot, it isn't taken into account.

Fix:
---
Adding events from yesterday and tomorrow to know
if they overlap with the slot

opw-3599209
Co-authored-by: Boulif Nasreddin <bon@odoo.com>

Forward-Port-Of: odoo/enterprise#57284
Forward-Port-Of: odoo/enterprise#52935

**Current behavior:**
Creating a promo type loyalty program and editing the
'products' field in the 'Among' section of the rule created by
default at the bottom of the form view before saving the
program will cause the products selected in this field to be
cleared upon saving the program.

**Expected behavior:**
Filling out this field of the default rule before saving the
overarching loyalty program should result in the same behavior
as doing so after saving the program. That is, the field should
save the user's input.

**Steps to reproduce:**
1. Create a new loyalty program in the Discount & Loyalty tab

2. Give it a name and, before saving the program, edit the
     'Products' field of the default rule that is created at
     the bottom of the form to have at least one value

3. Now save the program and observe that the 'Products' field
     has been cleared of the previously selected values

**Cause of the issue:**
In the form view for the loyalty.program there are two
instances of the field trigger_product_ids which are set to be
invisible unless creating a specific program type. This field
is set to be related to rule_ids.product_ids in its definition
within the loyalty.program class definition. Thus, when the
user saves the program and rule concurrently, the empty
trigger_product_ids field overwrites the product_ids field
and whatever the user had populated it with is cleared.

The reason it only happens to the default rule and not ones
which are manually added before saving the program is because
in the traverse_related() method in fields.py, only the first
record of the related field is returned to be modified. In this
case, it means only the first rule's product_ids field is
overwritten.

**Fix:**
Overwrite the create() method in program.loyalty and check if
the program being created is of type 'gift_card' or 'ewallet'
then, if so, delete the trigger_product_ids key,val from the
dictionary so it will not later override the products specified
in the loyalty rule.

opw-3669953

Forward-Port-Of: odoo/odoo#150418

### Steps to reproduce

* install `l10n_sa_edi`
* switch to a Saudi company
* deactivate the "EDI : Perform web services operations" scheduled action. (this will help ease the reproduction process)
* create and post two invoices for a partner that's an individual (not a company)
* manually run that scheduled action.

You should be met with a traceback.

### Cause

When a ZATCA document is submitted, the system performs several operations, two of which are important for this issue:
1. Generating a signature (`l10n_sa_invoice_signature`)
2. Using this signature to generate a QR code (`l10n_sa_qr_code_str`)

The QR code generation relies on the assumption that the signature (`l10n_sa_invoice_signature`) already exists, which is a reasonable expectation as the signature is typically created prior to the QR code.

However, complications arise when multiple documents are submitted simultaneously in a batch process. During batch processing, each document in the batch undergoes the same two operations mentioned above. The issue emerges due to the behavior of non-stored computed fields.

In Odoo, computed fields are evaluated in batches, meaning that if you access a computed field for one record, Odoo may also compute the same field for other records fetched in the same operation. For example, if you have two records, `A` and `B` such that `B.id in A._prefetch_ids`, and you access a computed field on `A`, Odoo will also compute this field for `B` at the same time.

This behavior leads to an issue when submitting two documents (`D1` and `D2`) together. The system will generate a signature and then compute the QR code for `D1`. However, when computing the QR code for `D1`, it inadvertently attempts to also compute the QR code for `D2` due to the batch computation behavior. Since `D2`'s signature has not yet been generated at this point, this results in an error.


opw-3696146

Forward-Port-Of: odoo/odoo#153810