Steps to reproduce:
-
- Install the DIN 5008 localization
- Settings > change the document layout to the DIN 5008 layout
- Add the German language to the database and make a contact German
- Create a sales order for that contact
- Click the Preview Button
- Click the View Details button

**Some terms such as 'Quotation No' are not transalted.**

Cause of the issue:
-
In the pot file, the `odoo-python` flags are not present on the keys of terms present in python files. As such the translations of these terms will not be loaded here:
https://github.com/odoo/odoo/blob/4c22cfe59972342363736effc8a37108dbed1f97/odoo/tools/translate.py#L1670 since the lines are not tagged as `PYTHON_TRANSLATION_COMMENT`. Prior to 17.1, (this change: commit 60f66ef21fe96c9418b0b3704149aea9dde70ad1) 
the translations were still loaded for the "wrong" reasons that they were not tagged as `JAVASCRIPT_TRANSLATION_COMMENT`: https://github.com/odoo/odoo/blob/d9e554bae879c294f39f10d1b666343431ed0e3d/odoo/tools/translate.py#L1681-L1683

Fix:
-
In order to load the translations of these terms we add the `odoo-python` flags to the keys corresponding to python translations. This can be done automatically by exporting the translations corresponding to the pot file and by replacing the current pot with the newly created file.

Even if it was not necessary for the fix to work, the keys have been changed accordingly in the associated po files (just as done everywhere else in the code base).

Notes:
-
- The keys of the nl.po were already updated and have not been changed.
- The translation of "Sales Order" in the de.po was changed by the export to the term that seems to be uniformly used in the code base.

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

In commit https://github.com/odoo/odoo/commit/bdede43e1ea4587185a9f37f051cee87a61cf488 an improvement was made to increase the scrollbar height on hover to make it easier to scroll. However chromium updated the way ::webkit-scrollbar works breaking the behavior on recent browser. On firefox the margin was applied without the change of height on the scrollbar creating a visual glitch on hover.

On chromium >121 the `scrollbar` property takes priority over the `::webkit`-x to keep the scrollbar styling with height change on webkit browser we have to apply the `scrollbar` property only on Firefox.

The mixin was used only on `website_sale` filter offcanvas and category horizontal scrollbar, this commit removes the mixin and customization on the offcanvas vertical scroll to make it consistent with the other offcanvas across website.

This PR also disables the scrollbar hover effect on touchscreens.

The transform was causing an issue on some devices displaying the scrollbar behind the items, thus it's now applied on the container.

Note:
We use not `.o_wsale_filmstip_fancy_disabled` to avoid the `scrollbar` property being set when the Javascript is not loaded yet.  Otherwise the scrollbar would be invisible until a hover from the user.

task-3718501

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

Forward-Port-Of: odoo/odoo#152456

Before this commit, calling _applyCommands with a lot of commands DELETE or UNLINK on a StaticList already containing a lot of commands was very slow. This happened for instance in the Automated Rule form view, click on "Add an action", and in the dialog form view, select a "mail" type, e.g. "Add followers". In that form view there's a many2many field "available_model_ids" which contains at first almost all models of the database (LINK commands). Switching to a "mail" model restricts those models to the ones inheriting from the thread mixin, i.e. it generates a lot of UNLINK commands. On runbot, in represents 1000+ LINK and UNLINK commands. This could take several seconds.

With this commit, we no longer iterate over all commands when applying a DELETE or UNLINK command. Instead, we simply push the command, store somewhere the information that we applied such a command, and after having processed all commands, we iterate (once) over this._commands, this.records and this._currentIds to do the necessary cleanups.

task 3599674

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

Previously, exporting BIS3 when there is a 0% tax in the invoice will results in the XML showing warning of UBL-CR-601. But if we do not include any TaxExemptionReason reason at all, a fatal error BR-E-10 will pop up.

Here is the details of those 2 rules:

```xml
(with context: /*/cac:TaxTotal/cac:TaxSubtotal/cac:TaxCategory
[normalize-space(cbc:ID) = 'E'][cac:TaxScheme/normalize-space(upper-case(cbc:ID))='VAT'])
      <assert id="BR-E-10" flag="fatal" test="exists(cbc:TaxExemptionReason) or
        exists(cbc:TaxExemptionReasonCode)">
          [BR-E-10]-A VAT breakdown (BG-23) with VAT Category code (BT-118)
          "Exempt from VAT" shall have a VAT exemption reason code (BT-121)
          or a VAT exemption reason text (BT-120). </assert>

and

(no context)
<assert id="UBL-CR-601" flag="warning" test="
  not((cac:InvoiceLine|cac:CreditNoteLine)/cac:Item/
       cac:ClassifiedTaxCategory/cbc:TaxExemptionReason)">
          [UBL-CR-601]-A UBL invoice should not include the InvoiceLine
          Item ClassifiedTaxCategory TaxExemptionReason </assert>
```

Based on these rules, we can conclude that:
- TaxExemptionReason must not appear in InvoiceLine/Item/ClassifiedTaxCategory
- TaxExemptionReason must appear (when some line in invoice has exempt tax) in TaxTotal/TaxSubtotal/TaxCategory

Previously, the TaxExemptionReason will appear on both places. This commit fixes that and adds a test to ensure that when a 0% tax is present, TaxExemptionReason only appear in TaxTotal/TaxSubtotal/TaxCategory

task-id: 3703206

Forward-Port-Of: odoo/odoo#154865
Forward-Port-Of: odoo/odoo#154055

Since [1] when the mega menu were first introduced, to make their edition possible, the bootstrap dropdown behavior was neutralized by removing the `data-[bs-]toggle` attribute.

In [2] when Bootstrap was upgraded to version 5.1.3, the `dataApiKeydownHandler` event handler that is called when up, down or escape are pressed raises an error if `data-bs-toggle` cannot be found on a previous sibling of the dropdown. This makes the approach chosen in [1] incomplete.

This commit avoids this issue by temporarily adding a class that is excluded from the event handler selector.
The patch must unfortunately be applied within bootstrap itself because the event handler is registered right after the method is defined and we have no way to access the registered event handlers afterwards. This makes it impossible to patch the called method from outside, nor its associated selector.

We cannot simply update the selector that was already patched by [3] because it is also used by other methods.

A test is included which should mitigate the risk of accidentally losing
this patch upon bootstrap upgrades.

Steps to reproduce:
- Create a mega menu.
- Edit the page.
- Open the mega menu.
- Click inside the mega menu content to have a cursor selection.
- Press the arrow up key, the arrow down key or the escape key.

=> An error dialog was displayed.

The same issue happened with a nested menu instead of a mega menu.

[1]: https://github.com/odoo/odoo/commit/1345702258adbfbee0d780dc22e552395e6d1df7
[2]: https://github.com/odoo/odoo/commit/971e5a91aab96d36129a823e03f1f9f1b1293968
[3]: https://github.com/odoo/odoo/commit/daca8fe4e3da4a5ad5fabf3730496a3919af8abc

task-3614926
opw-3741670

Forward-Port-Of: odoo/odoo#154864
Forward-Port-Of: odoo/odoo#154409

Description:
In a multi-company environment, `payment.provider` records are specific to each company. After activating Stripe on Company 1, you can set a Website for the record if you wish. If you wish to activate Stripe for Company 2, Odoo will use `.copy()` to create a new `payment.provider` record for Company 2. However, this will lead to differing incorrect behavior depending on the version.

On 16, a new `payment.provider` record will be created, but will be connected to the Website set on Company 1's provider.

On 17, Odoo will throw an error after a `check_company` call reveals that the Website set on the new record is for the wrong company, preventing the record from being created.

In both cases, the `.copy()` grabs the optional Website set on the existing `payment.provider` record to be used incorrectly for the new record.

Desired behavior after PR is merged:
The Website relation is always neutralized when Odoo creates a new Stripe `payment.provider` record using the `.copy()` method

opw-3683338

Forward-Port-Of: odoo/odoo#154521
Forward-Port-Of: odoo/odoo#154280

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

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.

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

Previously, exporting BIS3 when there is a 0% tax in the invoice will results in the XML showing warning of UBL-CR-601. But if we do not include any TaxExemptionReason reason at all, a fatal error BR-E-10 will pop up.

Here is the details of those 2 rules:

```xml
(with context: /*/cac:TaxTotal/cac:TaxSubtotal/cac:TaxCategory
[normalize-space(cbc:ID) = 'E'][cac:TaxScheme/normalize-space(upper-case(cbc:ID))='VAT'])
      <assert id="BR-E-10" flag="fatal" test="exists(cbc:TaxExemptionReason) or
        exists(cbc:TaxExemptionReasonCode)">
          [BR-E-10]-A VAT breakdown (BG-23) with VAT Category code (BT-118)
          "Exempt from VAT" shall have a VAT exemption reason code (BT-121)
          or a VAT exemption reason text (BT-120). </assert>

and

(no context)
<assert id="UBL-CR-601" flag="warning" test="
  not((cac:InvoiceLine|cac:CreditNoteLine)/cac:Item/
       cac:ClassifiedTaxCategory/cbc:TaxExemptionReason)">
          [UBL-CR-601]-A UBL invoice should not include the InvoiceLine
          Item ClassifiedTaxCategory TaxExemptionReason </assert>
```

Based on these rules, we can conclude that:
- TaxExemptionReason must not appear in InvoiceLine/Item/ClassifiedTaxCategory
- TaxExemptionReason must appear (when some line in invoice has exempt tax) in TaxTotal/TaxSubtotal/TaxCategory

Previously, the TaxExemptionReason will appear on both places. This commit fixes that and adds a test to ensure that when a 0% tax is present, TaxExemptionReason only appear in TaxTotal/TaxSubtotal/TaxCategory

task-id: 3703206

Forward-Port-Of: odoo/odoo#154865
Forward-Port-Of: odoo/odoo#154055

Since [1] when the mega menu were first introduced, to make their edition possible, the bootstrap dropdown behavior was neutralized by removing the `data-[bs-]toggle` attribute.

In [2] when Bootstrap was upgraded to version 5.1.3, the `dataApiKeydownHandler` event handler that is called when up, down or escape are pressed raises an error if `data-bs-toggle` cannot be found on a previous sibling of the dropdown. This makes the approach chosen in [1] incomplete.

This commit avoids this issue by temporarily adding a class that is excluded from the event handler selector.
The patch must unfortunately be applied within bootstrap itself because the event handler is registered right after the method is defined and we have no way to access the registered event handlers afterwards. This makes it impossible to patch the called method from outside, nor its associated selector.

We cannot simply update the selector that was already patched by [3] because it is also used by other methods.

A test is included which should mitigate the risk of accidentally losing
this patch upon bootstrap upgrades.

Steps to reproduce:
- Create a mega menu.
- Edit the page.
- Open the mega menu.
- Click inside the mega menu content to have a cursor selection.
- Press the arrow up key, the arrow down key or the escape key.

=> An error dialog was displayed.

The same issue happened with a nested menu instead of a mega menu.

[1]: https://github.com/odoo/odoo/commit/1345702258adbfbee0d780dc22e552395e6d1df7
[2]: https://github.com/odoo/odoo/commit/971e5a91aab96d36129a823e03f1f9f1b1293968
[3]: https://github.com/odoo/odoo/commit/daca8fe4e3da4a5ad5fabf3730496a3919af8abc

task-3614926
opw-3741670

Forward-Port-Of: odoo/odoo#154864
Forward-Port-Of: odoo/odoo#154409

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
...