Before this commit:
After selecting an image and clicking on crop button, crop widget displays and
vanish immediately and crop does not work. After clicking on screen, it raises
an error (Cannot read properties of null (reading 'removeChild').
After this commit:
The crop button works fine without raising any traceback.
Task-2804892
X-original-commit: 1ab1c15386f778b04eb78f26b1e0934f3329c6af
Part-of: odoo/odoo#90401
As the "Big Box" snippet contain two divs that have a background
it is invisible to change the background of the "Big Box"
Instead of choosing a background for the "Big Box", choose a background
for it's child divs.
Task-2678999
Forward-port-of: #81064
X-original-commit: e495544722a5d96f390d84452d0c84869a34391c
Part-of: odoo/odoo#90394
When clickbot opens a modal dialog, it should be detected and closed
properly. The `open` attribute was removed from the modal dialogs but
the clickbot test were successful by accident. Even though the modal was
not found, the script was still able to continue by clicking on other
elements.
By disabling the ability to click on other elements while a dialog is
open , this 590fa18cafe2c commit revealed the truth.
closesodoo/odoo#90393
X-original-commit: c5e2300cbb89519e002cf1784a8d6c6f68197742
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
*:
approvals
hr_apprasaisal
hr_payroll
hr_referral
fleet
hr
hr_attendance
hr_holidays
hr_recruitment
lunch
Change various access rights names to improve understandability for users.
Addition of an officer role in fleet with intermediate accesses
TaskID 2742855
closesodoo/odoo#87545
Related: odoo/enterprise#25741
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Previously, we were setting the ref to a component on ComponentWrapper
inside the onPatched hook, however, when mounting a component outside
the document (eg in a fragment) the patched hook is not supposed to be
called, but we need the ref to be set.
This commit fixes the issue by setting the componentRef in onRendered so
that it's available even when the component is mounted in a fragment.
closesodoo/odoo#90375
X-original-commit: 3013d89bcfe04be0207932b237d0e8ff8fb1d52b
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit:
redirect_url may have never been asssigned before being read
opw-2827002
closesodoo/odoo#90374
X-original-commit: 1aa35cba14528f413e9813707c406f31bfb07967
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Fixing docstring of new get_view method (odoo/odoo#87522),
to include it in the doc (and replace reference to the deprecated
method fields_view_get).
models.py:docstring of odoo.models.BaseModel.get_view:8: WARNING: Unexpected indentation.
models.py:docstring of odoo.models.BaseModel.get_view:9: WARNING: Block quote ends without a blank line; unexpected unindent.
+ some little improvements to the docstring
closesodoo/odoo#90372
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Step to reproduce:
- As mitchell admin
- Change user's/employee tz to something != UTC
- Go to time off
- Click on the calendar
Current behaviour:
- Wizard Popup with a timezone warning
- If the same thing is done with the 'New Time Off' button, the
warning is not present
Behaviour after PR:
- No Warning
- `request_unit_custom` should be False if `holiday_status_id` is
set which might happen in default_values.
opw-2828936
closesodoo/odoo#90357
X-original-commit: 5565eb9f3dc4259f1304373eff83f7d54a0db7be
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Remove most values uselessly specified because giving the same value as
the default one (see _DEFAULT_MANIFEST in odoo/modules/module.py)
* auto_install is Falsy by default
* author is Odoo SA by default
* summary & description are empty strings by default
* application is False by default
* test, demo, depends and data are empty lists by default
This will reduce noise/inconsistencies between manifests specifications,
simplify analysis of manifests content, ...
closesodoo/odoo#90209
Related: odoo/enterprise#26807
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
*: hr, im_livechat, snailmail, website_livechat.
This PR prepares the ground for the one introducing the new environment in the
discuss app. Indeed, tests will now use the mainComponentRegistry in order to mount
those components. Doing so, the parameters has{Discuss/Dialog/ChatWindow} will become
obsolete. Removing those parameters now helps reducing the noise in the main PR.
task-2582313
closesodoo/odoo#90120
Related: odoo/enterprise#26759
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Model pattern was too permissive, separator is the literal `.`
character, not any random thing.
Also remove unnecessary bracket expression, it's unnecessary when
matching a single item.
OPW-2836106
closesodoo/odoo#90107
X-original-commit: 320cdb4e85cb86915fa25cfda8f17e0a372e765e
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Raphael Collet <rco@odoo.com>
Current behavior:
When opening the giftcard popup in a PoS the focus would always
always go back to the first input field after typing in any other
input field.
Steps to reproduce:
- Install PoS and activate gift card
- Activate option "Scan an existing barcode and set a price"
- Start a PoS session
- Access the giftcard popup
- Select "Scan and set price on gift card"
- Type anything in the second input field
- The focus will go back on the first input field
opw-2825163
closesodoo/odoo#90081
X-original-commit: 84c129c7e05bb22e5dde272ab0a7cf8d4e1c2011
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
Description of the bug :
Registering a payment for two confirmed bills/invoices from different partners would result in a stack trace.
Steps to reproduce :
Create a bill from a specific partner and confirm it.
Create another from another partner, confirm it.
From the list view, select both those documents, click Register Payment.
The StackTrace appears.
FIX :
handled the case by setting the payment_difference field to 0.0 if the wizard contains multiple payment batches.
Modified some tests to detect this behaviour in the future.
closesodoo/odoo#89757
X-original-commit: def467e82b12c5ec7284ed9c966bb13ab3a77298
Signed-off-by: Laurent Smet <las@odoo.com>
The base model is modified in order to be able to make comparisons between
recordsets contained in lazy values. The isinstance method will always
return an error, so we consider that we receive a recordset and try to
access the `_name` and `_ids`. If an error is triggered, it was not a
recordset.
This way of doing it involves little change in performance (improvement
when it is good and decrease when there is an error) because we do not
test if it is a recordset before comparing it.
closesodoo/odoo#89141
Signed-off-by: Rémy Voet <ryv@odoo.com>
The test 'test_inactive_related_product_update' raises a ValueError
"Wrong value for product.template.detailed_type: 'product'".
(which causes the L10n nightly build many fails)
See https://github.com/odoo/odoo/pull/89468closesodoo/odoo#90339
X-original-commit: d0ff5fe311cd69a3068593142aff66b09f13c43d
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Julien Van Roy <juvr@odoo.com>
Previously, the useAssets hook would load the templates from the given
bundles into the qweb instance that was in the environment. In owl 2,
qweb is no longer in the environment, and templates need to be loaded in
the app.
This commit fixes that by exporting a function to load templates in the
main app from assets.js, when the main app is created, it should be
written on the function in a similar vein to renderToString, so that all
further calls to the function will load the templates in that app.
This commit also adds an actual lazy-loading test in the
test_assetsbundle module, as we don't want to pollute the manifest of
web with bundles that only exist for one specific test.
closesodoo/odoo#90122
Related: odoo/enterprise#26776
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
To find the 'country_code' field.
closesodoo/odoo#90255
X-original-commit: 980b7d09f63de17651e27d06170c8265530b99b1
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Purpose:
Increase usability of the Plan feature
This change implies changing 'hr.plan.wizard' m2o employee_id
field into m2m employee_ids field.
task - 2797331
closesodoo/odoo#88119
Related: odoo/enterprise#26264
Related: odoo/upgrade#3439
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Previously, the "debounce" util function was broken when passing
immediate=true, this was caused by the fact that the timeout was not set
to null after being executed, leading the function to always act as
though a call is already scheduled.
This commit basically rewrites the entire debounce function to fix this
problem, simplify the code, and make the API of debounce as close as
possible to underscorejs' debounce utility (with the exception that our
debounce function returns a Promise that gets resolved if and when the
call eventually goes through, and with the extra feature that the
debounced function has a cancel method to cancel the currently scheduled
call)
closesodoo/odoo#90297
X-original-commit: 24c39ba1744d83ef9712ef4d3df7db5baf35bc2e
Related: odoo/enterprise#26821
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Bug
===
If you install the module "Google Gmail", you won't be able to save
the settings without filling the API credentials which is annoying.
Task-2837340
closesodoo/odoo#90275
X-original-commit: c09473a4b975287fba8fb862430403d40da2e1ef
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When selecting products with a certain price in POS (e.g.: 24.99, 5.1), the
POS displays as if there were a discount while they aren't any (e.g.:
~~$24.99~~ $24.99 instead of just $24.99).
Step to reproduce the issue:
1. Install POS and Sales
2. In Sales settings activate "Discounts" and "Pricelists" with advanced price
rules
3. In the pricelist activate the discount policy
"Show public price & discount to the customer"
4. Create a product with a price of 24.99 without tax (or with tax but in the
end the total must be 24.99)
5. In POS select the product. It will show that the price of the product went
from 24.99 to 24.99, while we should simply see 24.99.
Solution: The issue comes from the backend that sends to the POS (upon loading)
some prices with invalid precision (giving, 24.990000000002 or 5.1000000005).
Consequently, following the logic of the POS, he think that the `price` and
`lst_price` are different because the `price` is rounded after applying any
discount (in this case, none). As I was not able to understand why we have such
a rounding in the backend, a workaround was to also round everything before
checking if there is a discount.
opw-2780083
closesodoo/odoo#90345
X-original-commit: 0a8391b4420f038056dfccc7d4391969a1fd97f5
Signed-off-by: Masereel Pierre <pim@odoo.com>
The user profile view is loaded using sudo
https://github.com/odoo/odoo/blob/183b021b2f01595caee7fa672cc5f212a9e63075/addons/hr/models/res_users.py#L172-L185
Therefore, there are in the view field nodes which are restricted to some groups,
the user might not belong to.
These fields need to be in the result of the `fields_get` in order for
the web client to be aware of them.
```
/web/static/src/legacy/legacy_load_views.js:75
Uncaught Promise > models[resModel][fieldName] is undefined
```
This issue happens since odoo/odoo#87522
with which the fields are no longer returned in `fields_view_get`,
renamed `get_view`.
The behavior before this revision was weird:
When calling `load_views` on `res.users` to get the profile form view,
you had fields added in the `fields` key of the `form` view
which were not present in the `fields` list key of the main result dict,
which is supposed to have all the fields of the model.
e.g.:
```
{
'fields': {
...
# address_home_id not there
},
'views_fields': {
'form': {
'arch': ...,
'fields': {
...
'address_home_id': ....
...
}
}
},
}
```
closesodoo/odoo#90331
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
The performFetch method has been rewritten in 14.5. Since then, we're relying
on the is_pending parameter given in the form data. This parameter is used as
if it was a boolean but is in fact a string representation of a boolean. This results
in incorrect attachments since this parameter is used to determine both the
res_model and the res_id of the created attachment.
closesodoo/odoo#90330
X-original-commit: 743face4357403861423ba242fa2be8ac364c546
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
*: sms, snailmail, test_mail
This commit introduces models that define records being 1:1 map with components,
as a step to move further to having essentially all business code in models.
Having code in models is desirable to have very maintainable code, thanks to
robust and declarative code with an ORM-like architecture.
Task-2831082
closesodoo/odoo#90320
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
When a an activity was already created, it is no longer to schedule it
when we change the type to a call or a meeting.
Step to reproduce the issue:
1. Create any activity (without scheduling it) on for example a Quotation
2. Edit this activity and change its type to meeting/call
There are no longer a Open Calendar Button, thus we can't schedule it.
Solution: The issue is simply that the Open Calendar button is only displayed
when the activity is not yet created (and if we have the appropriate category).
Instead of this condition, we should display this button if there are no event
already created.
opw-2824396
closesodoo/odoo#90028
X-original-commit: 1a66a3c4478c5b98951b658b6efbbd0b0d82166d
Signed-off-by: Anh Thao PHAM <pta@odoo.com>
Signed-off-by: Desausoi Laurent (lade) <lade@odoo.com>
Earlier in Odoo, JS views were defined by defining 4 elements: View,
Controller, Model, Renderer. This was complex in some way, because we
wanted to inherit behaviour as well, so it was necessary to think along
multiple dimensions to understand how the code was running.
Then, with Owl, we rewrote some views, and simplified them: views were
now just a Component. Most of the common behaviour now came from the
generic View component that instantiated the concrete view with the
proper informations. In practice, views were still split in views
(which was the equivalent of the Controller of earlier views), Model and
Renderer
Now, this commit reintroduce the Controller, and change the way views
are defined: by an object with multiple metadata, and an (optional)
props function to compute the actual props used by the view.
As a result, views are now much easier to extend/modify.
closesodoo/odoo#89889
Related: odoo/enterprise#26728
Signed-off-by: Géry Debongnie <ged@odoo.com>
A call to get_views returns an object with a "models" key, which is
a mapping from model names to their fields_get. There is an entry
for the main model, and an entry for each model for which there's
an inline x2many view inside the form view.
Before this commit, this was processed in the view service, s.t.
we generated a "fields" object and we added a "relatedFields" key
for x2manys fields, pointing to the fields_get of the related model.
This can create a structure with cycles, which can lead to problems
e.g. if we try to stringify it.
This commit prevents this by no longer nesting the related fields,
but rather keeping them in another structure.
closesodoo/odoo#90271
Signed-off-by: Géry Debongnie <ged@odoo.com>
When a doAction is done, the action service stringifies the given
action and writes it in the session storage, s.t. it can be
restored on F5 even if it's a dynamic action (i.e. not in DB).
However, the stringify operation may crash (e.g. if there is a
cycle in the action description). As we do not control what is
given to doAction, it can happen, and we have to properly handle
it.
This commit simply catches the error, and there's nothing more to
do in this case.
Part-of: odoo/odoo#90271
Processing failed mails is quite consuming operation that leads to browser
slowness or even crash. It's especially painful, because user doesn't see the
reason for it.
Bypass the problem by processing first 100 notifications only.
---
opw-2810681
opw-2754243
task-2806549
closesodoo/odoo#90246
X-original-commit: ec2d3550f32ae1e0585630b5b38befb73ddf2b26
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Signed-off-by: Ivan Elizaryev (iel) <iel@odoo.com>
Test case:
~ 16 000 products and using a pricelist with a fixed price for all products (so ~16 000 pricelist_item).
To reproduce:
Open PoS and add an item to the order
-> Very slow and not responsive: ~5 seconds to do the operation & around 2 minutes to fully load the PoS.
Issue:
`get_price` JS method is called several times and is a bit slow (~200ms). Mostly because of the linear search in the pricelist to check if the product does match.
Note that the function is called once per ProductItem rendered. Each time a product is added to the order the rendering is refreshed for all ProductItem displayed.
So the performance impact is significant if several of them are displayed.
To solve:
As the pricelist per Product.id is constant, we store the possible applied pricelist records on the product itself.
After this commit:
Order does take a few milliseconds to be added (2 ms VS 200ms)
Other notes:
A. With the current OWL version, it is not possible to force the render on only some of the ProductItem. A more appropriate fix could be done with "fine-grained reactivity" using a more recent OWL version
B. It was thought to store/cache the price value on the ProductItem itself. It does have its share of disadvantages (no check if the pricelist time period did start/end, etc.). Either way, with that being implemented, the PoS was still a bit slow (because of the 200ms per `_get_price` call)
OPW-2826122
closesodoo/odoo#90245
X-original-commit: 6f0bfb36a11e52e20b90ca85fc8847faadcdc95e
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Masereel Pierre <pim@odoo.com>
Add a check in 'AccountTestInvoicingCommon' to ensure that all
tests using it are run in post_install.
These tests cannot be run at install, thus they would be ignored
and wouldn't run on the Runbot.
X-original-commit: 659ee179e1beed962026e3abac1bda322c2ac964
[FIX] account,*: Ensure tests using TestInvoicingCommon runs
Add a check in 'AccountTestInvoicingCommon' to ensure that all
tests using it are run in post_install.
These tests cannot be run at install, thus they would be ignored
and wouldn't run on the Runbot.
closesodoo/odoo#90242
X-original-commit: ec36b403edda3fbe3b5bd5f30f31ef6bad680967
Related: odoo/enterprise#26791
Signed-off-by: Florian Gilbert <flg@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Steps:
Create a product with 2 attributes (2 values each):
> Color: black and white
> Size: small and large
Set their display type to "Pills".
Configure them so that only 2 combinations are possible:
> black - small
> white - large
Go to the website page (product configurator).
The first combination is set. Try to set another one.
Issue:
It is impossible to change neither attributes and, therefore, to change
the combination. With other display types, you can change one attribute,
even if it creates an unavailable combination. You are warned of this
fact, but you can change the other attribute and, by doing so, get back
on another available combination.
Cause:
The stylesheet does not allow to click on an incompatible variant
(attribute value).
Fix:
Delete this property.
opw-2762514
closesodoo/odoo#90236
X-original-commit: 089fda54e383c5f409bab1f2e4c822a4313864e0
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Onockx Audric (auon) <auon@odoo.com>
Fix a lost condition during a refactoring introduced by:
https://github.com/odoo/odoo/pull/82025
When dealing with payment transactions, a payment could be still in draft even after the call the 'action_post'.
closesodoo/odoo#90235
X-original-commit: 14cdb80774b638a39f430bc49c0c4d5a01925d90
Signed-off-by: Olivier Colson <oco@odoo.com>
Signed-off-by: Laurent Smet <las@odoo.com>
Set the survey in fullscreen (without the ribbon) and fixes the 404 page when
refreshing the survey management end page.
The end page has also been slightly modified by:
- hiding the header because it only contains relevant information when the
survey is running (link to join, number of person having answered the current
question, ...)
- hiding previous arrow which were not working (as the session is closed)
- hiding the next arrow which is not relevant and wasn't working
Task-2791044
closesodoo/odoo#90225
X-original-commit: dd6b007e174c19aeb45c1530aff987c393e36f70
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When a 'manual capture' is set for Authorize.net and a client
make a payment in several partial payments the user can capture
all the authorized transactions without crashing now.
Task - 2676914
closesodoo/odoo#90212
X-original-commit: 68b354f7353e3b5fd1faaad1b762c3c73a286f0f
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Horacio Tellez Perez (hote) <hote@odoo.com>
The SVL of in/out moves may be different because of rounding
To reproduce the issue:
(Need purchase,sale_management,stock)
1. In Settings, enable "Multi-Currencies"
2. Edit the USD currency:
- Rounding factor: 1.0
3. Create a product category PC:
- Costing Method: FIFO
4. Create a product P:
- Type: Storable
- Category: PC
5. Create a purchase order PO with one line:
- Product: P
- Quantity: 0.5
- Unit Price: 3.0
- Taxes: None
6. Confirm the PO and receive P
7. Create a sale order SO with 0.5 x P
8. Confirm the SO and deliver P
9. Inventory > Reporting > Inventory Valuation
Error: The quantity of P is zero but its total value is 0.50$
When receiving P, a SVL is created but does not round the value. So, we
have 0.5 x P in stock with a value equal to $1.50
Then, when deliver the product, the FIFO process is executed and create
a second SVL. However, this time the value is rounded:
https://github.com/odoo/odoo/blob/2e4fdcb84ba6375bb51fe71355168cebe2d922a0/addons/stock_account/models/product.py#L290
Therefore, the SVL of the out move has a value equal to $2. This
explains why, when checking the inventory valuation, the value is $-0.50
OPW-2724864
closesodoo/odoo#90251
X-original-commit: 306f3be81192eef504927e30483856669b36b047
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Some taxes had the wrong type of tax set when updating
from 12.0 to 13.0. The type should be Percentage of
Price instead of Group of Taxes.
opw-2801421
closesodoo/odoo#90249
X-original-commit: d8ff8d9a03f251cff4b87995e7ef3fad5a2b121f
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Signed-off-by: Fockedey Martin (mafo) <mafo@odoo.com>
When filtering on product templates with a negative operator, the
result
is incorrect
To reproduce the issue:
(Need mrp)
1. Create two products P_compo, P_finished:
- Internal Reference:
- P_compo: 123
- P_finished: 456
2. Create a BoM:
- Product: P_finished
- Components:
- 1 x P_compo
3. Manufacturing > Master Data > Bills Of Materials
4. Remove search filters and apply this custom one:
- "Product doesn't contain 456"
Error: P_finished's BoM is still in the list, but '456' is the internal
reference of P_finished, so this BoM should not be displayed
The filter is applied on the field `product_tmpl_id` of the BoM, which
leads to the override of `_name_search` in `product.template`. In this
method, a call to the `_name_search` of `product.product` is executed:
https://github.com/odoo/odoo/blob/5ff4eb022757d7a522ccb975f8eb64053ef9780b/addons/product/models/product_template.py#L456
which is a good thing because the version of `product.product` handles
the case of the Internal Reference (`default_code`)
https://github.com/odoo/odoo/blob/1e8982e4cf6b604e4da2773f10bdf6cf94c7e683/addons/product/models/product.py#L532-L538
So, the call to this `_name_search` will not return P_finished. However,
later on in the `_name_search` of `product.template`, we call the
`_name_search` of `super` with the same domain (i.e., 'not 456 in name')
https://github.com/odoo/odoo/blob/5ff4eb022757d7a522ccb975f8eb64053ef9780b/addons/product/models/product_template.py#L474-L485
This is the issue: it leads to the `_name_search` of `BaseModel`, which
is the classic version: it does only consider the record's name. So,
this call will return P_finished.
In the `_name_search` of `product.template`, there are actually two
calls to `super`. Considering the commits [1] and [2], it seems that the
goal is the same in both cases: find the `product.template` that do have
any variant yet. However, in the first commit, the domain given to
`super` excludes the templates that have at least one variant, which is
not the case with the second commit (the "problematic" one).
Since both codes have the same goal, we should merge them by keeping the
best idea of each one. From [1], we keep the idea of restricting the
domain: we only look for templates that do not have any variant.
However, this domain needs to be improved: we need to include the
templates whose all variants are archived. From [2], we keep the idea of
looking for the templates outside the `while True` loop. This allows us
to do the search only if required.
[1] 21ae503
[2] 99bae2c
OPW-2791255
closesodoo/odoo#90248
X-original-commit: 942814844e982cbaec2329709c6ba9dd810d0c3f
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
When converting an element to a list element, we didn't preserve that
original element's attributes. As a consequence the text direction was
lost.
closesodoo/odoo#90247
X-original-commit: 0731ff677491d80540fa2ffc645fd2b471a9f61c
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
This introduces a "direction" option on the editor to set the text
direction of the editor (passed by Odoo based on the localization), and
a Powerbox command to switch said direction on a given block. This
allows users to mix several text directions within the same text, eg.
when quoting Hebrew in an English text.
task-2814004
X-original-commit: 693df325588ccaf6385c9f610709f687ccdf61a8
Part-of: odoo/odoo#90247
Hiral Bhavsar