Currently, an exception is generated when the user tries to sort employees by "Next Activity Deadline" in the list view.

Stack Trace:
```
ValueError: Cannot convert field hr.employee.activity_date_deadline to SQL
  File "odoo/http.py", line 2251, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1827, in _serve_db
    return self._transactioning(_serve_ir_http, readonly=ro)
  File "odoo/http.py", line 1847, in _transactioning
    return service_model.retrying(func, env=self.env)
  File "odoo/service/model.py", line 134, in retrying
    result = func()
  File "odoo/http.py", line 1825, in _serve_ir_http
    return self._serve_ir_http(rule, args)
  File "odoo/http.py", line 1832, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 2057, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 220, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 739, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "addons/web/controllers/dataset.py", line 38, in call_kw
    return self._call_kw(model, method, args, kwargs)
  File "addons/web/controllers/dataset.py", line 34, in _call_kw
    return call_kw(request.env[model], method, args, kwargs)
  File "odoo/api.py", line 458, in call_kw
    result = getattr(recs, name)(*args, **kwargs)
  File "addons/web/models/models.py", line 46, in web_search_read
    records = self.search_fetch(domain, specification.keys(), offset=offset, limit=limit, order=order)
  File "addons/hr/models/hr_employee.py", line 246, in search_fetch
    return super().search_fetch(domain, field_names, offset, limit, order)
  File "odoo/models.py", line 1619, in search_fetch
    query = self._search(domain, offset=offset, limit=limit, order=order or self._order)
  File "addons/hr/models/hr_employee.py", line 334, in _search
    return super()._search(domain, offset, limit, order, access_rights_uid)
  File "odoo/models.py", line 5413, in _search
    query.order = self._order_to_sql(order, query)
  File "odoo/models.py", line 5225, in _order_to_sql
    term = self._order_field_to_sql(alias, field_name, sql_direction, sql_nulls, query)
  File "odoo/models.py", line 5283, in _order_field_to_sql
    sql_field = self._field_to_sql(alias, field_name, query)
  File "odoo/models.py", line 2812, in _field_to_sql
    raise ValueError(f"Cannot convert field {field} to SQL")
```

This is because the 'activity_date_deadline' field is a non-storable field, so the value error is raised from Line [1] as the field is non storable.

Before saas-17.2, when we tried to sort records with this type field, it did not sort records; instead, it wrote a logger warning with Line [2], but after the code refactor with commit  https://github.com/odoo/odoo/commit/b177b058be1531c3d2af2b591c22591c19240d33, Line [2] was removed, and now Line [1] throws an error when the sorting field is non-storable. 

This PR fixes the above issue by removing the `{'allow_order': '1'}` option from the list  view of the field 'activity_date_deadline'. 

[1] - https://github.com/odoo/odoo/blob/b4db0e2cb4e45830662cbb57559c6350ac621806/odoo/models.py#L2811-L2812
[2] - https://github.com/odoo/odoo/blob/5c5b4d991423e0282d06a98e5677977d53dc0817/odoo/models.py#L5318-L5320

sentry-5152111900

(master) account_asset: Sell or Disposal adheres to IFRS/IAS 16 - Derecognition of Assets
=
Impacted versions:
-

master

Current behavior:
-

- Configure an Asset Model like the following
<img width="1043" alt="Screen Shot 2019-08-14 at 5 55 22 AM" src="https://user-images.githubusercontent.com/7598010/63016041-38bfbc80-be58-11e9-9c3d-532892f500e9.png">

- Configure Account for Fixed Asset as the following
<img width="1043" alt="Screen Shot 2019-08-14 at 5 57 13 AM" src="https://user-images.githubusercontent.com/7598010/63016168-8b997400-be58-11e9-9fd0-25c7339f7bed.png">

- Create a new Vendor Bill and Validate it.
<img width="1073" alt="Screen Shot 2019-08-14 at 5 59 39 AM" src="https://user-images.githubusercontent.com/7598010/63016237-c6031100-be58-11e9-8c73-c389ca1b1ae8.png">

- Let us check on the newly created Asset in the button upper right.
<img width="1073" alt="Screen Shot 2019-08-14 at 6 01 15 AM" src="https://user-images.githubusercontent.com/7598010/63016314-f64aaf80-be58-11e9-9b83-b7ef10cb3f19.png">

- Confirm it and the run depreciation for the already past depreciations.
<img width="1073" alt="Screen Shot 2019-08-14 at 6 03 15 AM" src="https://user-images.githubusercontent.com/7598010/63016450-50e40b80-be59-11e9-926d-b0f1df4812d7.png">

- Hit Sell or Dispose button and set a date on the wizard.
<img width="975" alt="Screen Shot 2019-08-14 at 6 05 05 AM" src="https://user-images.githubusercontent.com/7598010/63016517-8557c780-be59-11e9-8d75-82829aec0904.png">

- Let us check on the newlyJournal Entry created for the disposal of this asset.
<img width="1068" alt="Screen Shot 2019-08-14 at 6 05 52 AM" src="https://user-images.githubusercontent.com/7598010/63016594-b59f6600-be59-11e9-8c9f-7f6c959f2924.png">

Issue
-
**Here is the actual issue**. Sell or Dispose button creates a Journal Entry where the remaining value of the asset is sent to Depreciation Expense versus Cumulated Depreciation

Regarding [IFRS/IAS 16](http://eifrs.ifrs.org/eifrs//bnstandards/en//2019/IAS16.pdf) -Derecognition - Paragraph 68 & 71
<img width="771" alt="Screen Shot 2019-08-14 at 6 15 39 AM" src="https://user-images.githubusercontent.com/7598010/63017096-006dad80-be5b-11e9-8542-d053d4adc976.png">
<img width="771" alt="Screen Shot 2019-08-14 at 6 16 00 AM" src="https://user-images.githubusercontent.com/7598010/63017101-04013480-be5b-11e9-82a9-5ec5e2a5a130.png">

This supported by the fact that for [IFRS® Taxonomy Illustrated](https://www.ifrs.org/issued-standards/ifrs-taxonomy/ifrs-taxonomy-illustrated/#illustrated2019) 
For `[822100] Notes - Property, plant and equipment` report it must properly identify the parties where impairment, retirement or sell of assets have occurred 
![Screen Shot 2019-08-14 at 6 22 11 AM](https://user-images.githubusercontent.com/7598010/63017499-1cbe1a00-be5c-11e9-8504-4a79808d5c23.png)

Furthermore in `[520000] Statement of cash flows, indirect method` report it must be properly identified in the regarding adjustment other than the Depreciations.
![Screen Shot 2019-08-14 at 6 30 18 AM](https://user-images.githubusercontent.com/7598010/63017865-05336100-be5d-11e9-852c-069e0fa12226.png)

Expected behavior:
-

With the new approach we should have some settings like this one. 
<img width="1072" alt="Screen Shot 2019-08-14 at 6 34 03 AM" src="https://user-images.githubusercontent.com/7598010/63018067-9571a600-be5d-11e9-8010-b6a81fd9af0f.png">
Notice there is a new field for the Disposal of the Asset.

- Execute all the previous step to accomplish a new Asset until the step where you can sell or dispose it.
<img width="1072" alt="Screen Shot 2019-08-14 at 6 40 24 AM" src="https://user-images.githubusercontent.com/7598010/63018438-745d8500-be5e-11e9-807c-a159e6b5653a.png">


- Hit the Sell or Dispose button. We can see that 
-- The whole value of the asset has been derecognized
-- The Cumulated Depreciation has been reverted.
-- The Remaining Value of the asset has been recorded as Impairment Expense

<img width="1072" alt="Screen Shot 2019-08-14 at 6 41 11 AM" src="https://user-images.githubusercontent.com/7598010/63018459-86d7be80-be5e-11e9-9919-7bb2d14370f5.png">

In this way we could afford to properly:
- Have Adjusted Assets for Balance Sheet report.
- Have a PP&E report.
- Have a Cash Flow Indirect method the right way.
- Have an Income Statement where the Impairment is set aside from the Depreciation Expenses.

(master) account_asset: When Cancelling an invoice with Draft assets. Assets standstill
=
[FIX] account_asset: Delete draft assets if originating journal items get cancelled. Archive the ones that are running or done.


Impacted versions:
-

master

Current behavior:
-

- Configure an Asset Model like the following
<img width="1060" alt="Screen Shot 2019-08-15 at 10 45 59 PM" src="https://user-images.githubusercontent.com/7598010/63142201-7fbfc600-bfae-11e9-8246-96516c0971ad.png">


- Configure Account for Fixed Asset as the following
<img width="1043" alt="Screen Shot 2019-08-14 at 5 57 13 AM" src="https://user-images.githubusercontent.com/7598010/63016168-8b997400-be58-11e9-9fd0-25c7339f7bed.png">

- Create a new Vendor Bill and Validate it.
<img width="1073" alt="Screen Shot 2019-08-14 at 5 59 39 AM" src="https://user-images.githubusercontent.com/7598010/63016237-c6031100-be58-11e9-8c73-c389ca1b1ae8.png">

- We can inspect that a new asset in draft state is created in the upper right button in the invoice. 
<img width="833" alt="Screen Shot 2019-08-15 at 10 50 41 PM" src="https://user-images.githubusercontent.com/7598010/63142386-3754d800-bfaf-11e9-8556-f810df18225a.png">

- No depreciation board is yet set on the asset.
<img width="1086" alt="Screen Shot 2019-08-15 at 10 51 02 PM" src="https://user-images.githubusercontent.com/7598010/63142392-420f6d00-bfaf-11e9-9267-fe4658accb66.png">

- For whatever the reason. You have to amend the invoice so you cancel it to amend it. In cancel state we are able to see that my invoice is still linked to an asset.
<img width="1086" alt="Screen Shot 2019-08-15 at 10 54 05 PM" src="https://user-images.githubusercontent.com/7598010/63142484-9f0b2300-bfaf-11e9-993e-84f55bc3bc36.png">

- Though when checking on the linked asset there is none. It have been deactivated.

<img width="1086" alt="Screen Shot 2019-08-15 at 10 57 19 PM" src="https://user-images.githubusercontent.com/7598010/63142617-18a31100-bfb0-11e9-99da-3189a3fdde3a.png">

<img width="1086" alt="Screen Shot 2019-08-15 at 10 56 12 PM" src="https://user-images.githubusercontent.com/7598010/63142584-fa3d1580-bfaf-11e9-9d4c-163ff8a1eb57.png">

- So far so good. Let us know `Reset to Draft` our cancelled invoice and reuse. Make some changes. Let it be that Price of the asset was wrong. and try to validate our fixed invoice.
<img width="1086" alt="Screen Shot 2019-08-15 at 11 00 48 PM" src="https://user-images.githubusercontent.com/7598010/63142717-8c451e00-bfb0-11e9-8772-3dc371e14a0d.png">

- In trying to do something on the Archived Asset we are now greeted with this Warning.
<img width="1086" alt="Screen Shot 2019-08-15 at 11 02 12 PM" src="https://user-images.githubusercontent.com/7598010/63142796-e1812f80-bfb0-11e9-8046-9585f7ab5a14.png">

Now we are locked with a draft invoice linked to an archived asset with no way to make something on the archived asset.

Expected Behavior
=
At invoice cancelation, get rid of the Draft Assets.

Actions Performed
=

- Drafts assets are now Deleted
- Other assets just get Archived just the way it was before but using existing method `action_archive()` (more on this activity in coming issues)
- `sudo()` method on `search()` for assets has been left to allow actually searching if user has no read privileges.
- `sudo()` method on `unlink()` & `action_archive()` methods is not deployed because user entitled to do should be granted such as privileges and not the superuser.

…neration

Purpose
=======

When generating the work entries the first time for older contracts,
we try to generate the work entries for several months/years, instead of
only the current month for example.

The reason if that the date_generated_from and date_generated_to fields
are there to avoid having gap on the generated work entries.

If they were generated from January to March, and we try to generate
them in July, then we generate the work entries for April, Mai, June,
and July, so that if we remove work entries on a given day, we don't
try to re-generate them afterward.

If we move the cursors to the start date when they are equal, instead of
generating 138300 records for 100 employees who have a contract starting
on the 1rst of January 2018, to generate work entries till the 31nd of
August 2020, then generate 7900 records.

This represents 17.5 times less records to create, and it allows to use
generate the records on real database for the first time without risking
to face a timeout.

TaskID: 2321853

Currently, receipts are not accounted for in the model 347 report (issue 1). The same happens for invoices for which a payment has been registered (issue 2).

### Setup

* install `l10n_es_reports`
* switch to a Spanish company

### Steps to reproduce issue 1

* with a new partner, create and confirm a customer receipt for more than €3005.06 (threshold for appearing in the report)
* open the model 347 tax report

We would expect the new partner to be listed in the report, but they aren't.

### Steps to reproduce issue 2

* with a new partner, create and confirm an invoice for more than €3005.06
* if you open the model 347 report, you will see the new partner listed there
* go back to that invoice and register a payment for it.
* open the model 347 report again

We expect the new partner to still be listed, but they are not.

### Cause

issue 1: receipts are missing in the corresponding domains.
issue 2: all account moves are used to calculate the threshold. This means that, for example, invoices and payments can cancel each other out in the calculation.

opw-3816370

Forward-Port-Of: odoo/enterprise#60353
Forward-Port-Of: odoo/enterprise#59343

**Steps to reproduce:**
- Install Contacts, Accounting and l10n_mx_edi_extended
- Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE)
- Go to company form and configure its address (*)
- Create a US customer (e.g. Foreign Customer) (*)
- In Accounting settings:
  * activate "Customer Addresses"
  * use Mexican Bank for automatic currency rates (*)
- Configure a product for external trade (e.g. Office Chair) (*)
- Create an invoice: (*)
  * Customer: Foreign Customer
  * Delivery Address: [different than customer] (e.g. Deco Addict)
  * Product: Office Chair
  * Incoterm: EX WORKS
  * External Trade: Definitive
- Confirm the invoice
- Generate CFDI via "Send & Print" button

(*) https://www.odoo.com/documentation/17.0/applications/finance/fiscal_localizations/mexico.html#external-trade

**Issue:**
A traceback is raised because an inexisting method (i.e. `_get_customer_cfdi_values`) is called.

**Cause:**
The missing method has been renamed from "_l10n_mx_edi_get_customer_cfdi_values" to "_get_customer_cfdi_values" during a refactoring, but the original method has been deleted without implementing the new one.

**Solution:**
"_l10n_mx_edi_get_customer_cfdi_values" method was used to generate the data for the delivery address without altering the existing CFDI values.
These data were used to populate the external trade data of the CFDI.
"_add_customer_cfdi_values" method is similar to removed "_l10n_mx_edi_get_customer_cfdi_values" method, except that it also updates "receptor" in the CFDI.
It is used with a copy of the cfdi values to compute the values for the delivery address.

opw-3849153

Before this commit, when the user goes to Timesheets app, he could get a traceback because the JS code does manage the case `get_billable_time_target` method could return an empty when no employee is linked to the current user.

This commit fixes the issue by managing that case and hide the leaderboard as we should expect since the billable target is not found for that current user.

Steps to reproduce the issue
============================
1. Create a new employee
2. Link that employee to a new user
3. Remove the user to the employee (unset Linked user field)
4. Log in as that new user
5. Go to timesheets app

Current Behavior
================
A traceback is occured because the rpc called returned an empty list instead of a list containing at least one object to get the billable target for the current user.

Expected Behavior
=================
The grid view of Timesheets app should be loaded as expected and the leaderboard should not be displayed since no data is found to get the billable target for that current user.

opw-3862635
opw-3866805
opw-3864353

# Introduction:

`JSON.stringify` was used to serialize the properties for the `/article`
command instead of the classical `encodeDataBehaviorProps` which also uses
`encodeURIComponent` above the `JSON.stringify`, to avoid having some special
characters as an attribute value.

# The issue:

`html_field.js:getEditingValue` is recovering the current value in the DOM using
`innerHTML` which converts some characters from tag attributes to HTML entities,
i.e.: `"` for `"`.

`mail.py:html_normalize` is using `lxml.html.tostring` is receiving such a
string with HTML entities, and is returning a string without HTML entities.

The database value (without HTML entities) is later given to the `html_field` as
a prop and is used as a comparison reference (`updateValue`) with the current
value in edition (that is still being converted to have HTML entities). Since
both values are different, the field is considered as dirty and in need of being
saved, which will trigger a write, even though the normalized value is the
same.

# Fix:

Using `encodeDataBehaviorProps` to serialize props as the Behavior anchor
attribute (like for any other Behavior) will prevent the use of characters that
are being converted to HTML entities.

In order to update existing `/article` blocks, the behavior will overwrite its
`data-behavior-props` attribute when it is mounted in edit mode.

task-3853291

Forward-Port-Of: odoo/enterprise#60775
Forward-Port-Of: odoo/enterprise#60177

**Steps to reproduce:**
	1- Create an allocation with validity date (e.g. 01-01-2024 -> 30-06-2024)
	 and another one starts after the first one (e.g. 01-07-2024 -> 31-12-2024)
	2- Go to Time off module and select a date in the second allocation's period
	3- Click on the Time off type dropdown menu
	4- You will see the first allocation displayed not the second one

**Current behavior before PR:**
The display name of some leaves gets computed in a wrong way.
This is happening because after fetching the right allocation
we compute the display name but this time we don't have
the 'default_date_from' in context so since
it became one of the fields that triggers '_compute_leaves'
https://github.com/odoo/odoo/blob/17.0/addons/hr_holidays/models/hr_leave_type.py#L218:L219
we compute the leaves once again but the target_date will be none
and it will get assigned with today's date in 'get_allocation_data'
https://github.com/odoo/odoo/blob/17.0/addons/hr_holidays/models/hr_leave_type.py#L380:L381

**Desired behavior after PR is merged:**
This has been solved by saving the date attribute in the context
with another name as when computing the display_name we call sudo so clean_context()
removes the 'default_' context keys. Now when it gets removed we are
going to have the same value but with another name.

opw-3797696

## Problem
Before this commit, adding a dropdown to a kanban view via `web_studio` didn't work.
Steps:
- Install `web_studio`
- Install a module containing no dropdown on the kanban view (e.g. `sale_management`)
- Modify the kanban view of this module on studio
- Click on the 3 small dots on the kanban-card and add the dropdown
- Confirm
- Exit studio
- Try changing the color of one of the kanban-cards via the newly added dropdown
- Traceback

## Explanation
Here's how adding a dropdown to the kanban view normally works in studio:
Python:
- Create a new `x_color` field in the model
- Add this new field to the view in question
- Add a dropdown containing `.oe_kanban_colorpicker` and a `data-field` containing `x_color`.
- Change the attributes of the first element in the kanban-card to add a color="x_color".

Javascript:
If the color is changed, this code is triggered

https://github.com/odoo/odoo/blob/0fcb34dd3ba3bbd7f422c627e27c96089b29b044/addons/web/static/src/views/kanban/kanban_record.js#L302-L306

which dynamically updates the `colorpicker` field with the new value via the value of arch `colorField`.
Except that in our case `colorField` is `color` and not `x_color`.

Then, as the `web_studio` python code adds a `color="x_color"` attribute, instead of `colorField` it's `cardColorField`.

https://github.com/odoo/odoo/blob/3c356a40f7d6da5aff8a8e7f6ebb9ea8cc9b3861/addons/web/static/src/views/kanban/kanban_record.js#L266-L269

This code is obsolete because it adds `oe_kanban_color_X` to `o_kanban_record ` instead of adding it to its first child `oe_kanban_card`.

So we have several problems:
- Use of `cardColorField` instead of `colorField`.
- Color style added to wrong HTML element
- KanbanArchParser searches for the colorpicker's `data-field` only in `kanban-box`, whereas it is often (including in studio) put in `kanban-menu`.

## Commits
### Commit 1: [[FIX] web: Use kanban-menu template in arch kanban_arch_parser](https://github.com/odoo/odoo/pull/160483/commits/bb0cf9ef09ac29233b99b64077c9b31bcd4a04a0)

This commit modifies the way kanban_arch_parser retrieves `colorField`.

Previously, the parser tried to retrieve only `colorField`
(the `data-field` attribute of `.oe_kanban_colorpicker`) from `kanban-box`.
Except that in most cases `.oe_kanban_colorpicker` is defined in
`kanban-menu` and not `kanban-box`.

for example:

https://github.com/odoo/odoo/blob/31107fb4cc9cf5dc2da21cbfef58dae722c73922/addons/crm/views/crm_lead_views.xml#L554-L559
https://github.com/odoo/odoo/blob/c6978c3fc4f828d970d45ebdaa4a35b44f3d09ce/addons/project/views/project_task_views.xml#L544-L550
https://github.com/odoo/odoo/blob/c6978c3fc4f828d970d45ebdaa4a35b44f3d09ce/addons/project_todo/views/project_task_views.xml#L28-L31
etc.

As a result, this code was always ignored and we always fallback on `||"color"`.
```js
 const colorField = (colorEl && colorEl.getAttribute("data-field")) || "color";
```

Now `KanbanArchParser` checks both `kanban-box` and `kanban-menu` and
finally fallbacks to `color`.


### Commit 2: [Put kanban color classes in the right place](https://github.com/odoo/odoo/pull/160483/commits/73844cd42a389020bd4a7bd47ed48c4652fa7e4d)

After this commit, `colorField` is used instead of `cardColorField` to
handle color change from the dropdown of cards in the kanban view.

The value of `colorField` is observed in order to adapt the HTML classes
of `oe_kanban_card` (first `DIV` of `o_kanban_record`) by
adding/removing `oe_kanban_color_X` (where X is an index representing a color).


A commit has also been made in the enterprise section to remove unnecessary code from the `web_studio` controller, which before this pull request was used to add a color="x_color" attribute that we no longer use.

https://github.com/odoo/enterprise/pull/60072


opw-3823860

Forward-Port-Of: odoo/odoo#160483

**[FIX] payment(_stripe): adapt validation currency to payment method**

When payment details are tokenized through a validation operation, the currency to use was usually (except overrides) chosen as that of the payment provider's company. This sometimes caused compatibility issues if the selected payment method did not support the company's main currency. For example, the SEPA Direct Debit payment method only supports the EUR currency.

This commit allows passing a payment method when getting the validation currency so that only supported currencies can be returned.

---

**[FIX] payment_(buckaroo, stripe): updated the PM based on provider codes**

When processing a transaction, the payment method was searched based on the received code (e.g., 'sepa_debit') that was compared with the `payment` module's generic codes (e.g., 'sepa_direct_debit'). This commit ensures that we now compare with provider-specific codes for Buckaroo and Stripe.

In practice, this mistake had little to no impact as most provider codes match the generic ones, and we fall back onto the payment method selected by the user if we can not find a more accurate one based on the code.

Versions
--------
- saas-16.3+

Steps
-----
1. Set timezone of User and browser to America/Los_Angeles;
2. go to Time Off;
3. click on calendar to create a new leave.

Issue
-----
Date defaults to the day before the selected date.

Cause
-----
Commit 0a0c6917b5e21e829e14ad271de6e2117e4a7126 added a TZ conversion in JS to add default start & end times for leaves. The issue is that it assumes the context values are always datetime strings, therefore always using `deserializeDateTime`, which does a timezone conversion from UTC to local time, which is incorrect when the context values are date strings.

For a UTC-7 zone like America/Los_Angeles, it deserializes a date string like `'2024-01-01'` to `'2023-12-12 17:00:00'` (7 hours before midnight). It then sets the start hour to 7, and serializes it back to UTC, adding 7 hours, resulting in `'2023-12-12 14:00:00'`. Instead, Jan 1, 7 AM in America/Los_Angeles should convert to `'2024-01-01 14:00:00'` UTC.

Solution
--------
Use `deserializeDate` instead of `deserializeDateTime` when the `default_date_{from,to}` in the context is a date rather than a datetime. This way, `'2024-01-01'` gets deserialized into `'2024-01-01 00:00:00'` local time. When this value gets used for the default hours, `'2024-01-01 07:00:00'` local time will get serialized to `'2024-01-01 14:00:00'` UTC as expected.

opw-3757712

Forward-Port-Of: odoo/odoo#161838

Given the changes in [1] and subsequently in [2], which in some way
counteract the RTL adjustment, it is necessary to eliminate the rtlcss
directive from the carousel CSS to ensure the correct behavior.

Steps to reproduce:

- Enter in edit mode.
- Drag and drop an image gallery and a carousel snippet.
- Navigate to the theme tab.
- Add an RTL language (Arabic, for instance).

Bug :

- The images slide in incorrectly during transitions. In RTL mode, when
  clicking on the left chevron, the next image should appear, not the
  previous one.

If we have three slides numbered 1, 2, and 3
- In RTL mode: Clicking left should navigate from 1 to 2 to 3 and then
  back to 1.
- In non-RTL mode: Clicking left should navigate from 1 to 3 to 2 and
  then back to 1.

The directional Font Awesome icons (classes starting with `fa-` and
ending with `-right` or `-left`) are not flipped in the mobile viewport
as a result of [3]. Necessary adjustments have been implemented
to prevent this behavior.

Upon investigation, a more significant bug was discovered regarding the
'oi-...-[right/left]' icons. These icons were not flipped appropriately
in the frontend when the webpage context was set to an RTL language. A
pull request has been created and merged to address this issue [4].

More info on rtlcss [here]

[1]: https://github.com/odoo/odoo/commit/ebb61753bf3d3dd8d3f53db088112b9e4beb813d
[2]: https://github.com/odoo/odoo/commit/c48f57ea2538ad51e00ac27d58f8e191781444f3
[3]: https://github.com/odoo/odoo/commit/be375bb2a886edd002f042355455a71fcac4daf5
[4]: https://github.com/odoo/odoo/pull/157214
[here]: https://rtlcss.com/learn/usage-guide/value-directives/#tip

opw-3747848

Forward-Port-Of: odoo/odoo#161770
Forward-Port-Of: odoo/odoo#154734

If the "generic" routes (i.e., the ones created from the master data)
are company-specific, the user won't be able to create a new comapny
anymore.

To reproduce the issue:
1. In Settings, enable "Multi-Step Routes"
2. Enable all companies
3. Inventory > Configuration > Rules:
   - For each Manufacture rule:
     - If its route does not have any company:
       - Set the route's company equal to the one of the rule
4. Create a new company

Error: a Validation Error is raised: "Rule [...] (Production) belongs
to \<new company\> while the route belongs to \<an existing company\>."

Creating a company leads to the creation of the WH and its rules. At
some point, we create/update the global rules. Let's look at the
Manufacture one. We will provide all the required values for its
creation:
https://github.com/odoo/odoo/blob/270d8aa06bb37b4a01f01a7274062e3f88ca2a1c/addons/mrp/models/stock_warehouse.py#L112-L128
As you can see, for the `route_id` field, we try to find a global
route. But here is the issue: in this `_find_global_route`, we will
find the "generic" one thanks to the provided XML_ID. But, step 3,
we set a company on that route. As a result, here, we try to create
a rule for a company X linked to a route that belongs to a company Y,
hence the validation error:
https://github.com/odoo/odoo/blob/dc58d7913131f1f4dbeb0e3337e61e0b21f6f0d9/addons/stock/models/stock_rule.py#L107-L108

OPW-3790512

Forward-Port-Of: odoo/odoo#161888
Forward-Port-Of: odoo/odoo#161820