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