Issue
- Install Contacts
- Create a contact: Company A
- Add a contact to that company: John
- Add a private address for John
- Save
- Change John's company
- Go back
- Look for the private address
The display_name contains the old
company name
Cause
The private address display_name is
not recomputed when the contact's
company changes.
Solution
Recompute child_ids display_name
when the company changes.
OPW-2253785
closesodoo/odoo#51450
X-original-commit: b112c8921eec60c63cead37c74946d06b499eb6a
Signed-off-by: Jason Van Malder (jvm) <jvm@odoo.com>
This restricts the attributes of a BaseModel instance to `env`, `_ids`
and `_prefetch_ids`. This way, one can only assign fields on a record;
other assignments are programming errors.
This also reduces the memory footprint of records from 168 to 64 bytes
(-62%), and makes their instanciation faster.
closesodoo/odoo#51075
Related: odoo/enterprise#10529
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
PURPOSE
=========================
The goal of this task is to set up some kind of guidelines to make
kanban views consistent.
It is fine having different kanban views, but if a UI element is shared
among several kanban views, it should behave/look the same so the user
knows what to expect.
Kanban views can be split into two types:
==> 'documents' kanbans, such as res.partner, crm.lead, etc.
- those records are created/edited often, numerous
- 'opening' the card means accessing the record
==> 'dashboard' kanbans,such as stock.picking.type,account.journal, etc.
- those records are not created/edited often, there are much less numerous
- usually presented as dashboard, where 'opening' the card means
accessing a set of related 'documents' (clicking on a account.journal
to access account.move, or stock.picking.type to access stock.picking)
- configuration of the 'card record' is done through a dropdown to
access configuration
Here are some guidelines for consistency. Bear in mind that those are
not rules, but guidelines for consistency that we'd like to keep in
mind when designing.
==> 'documents' kanbans
- the record is accessed through global click
- the user avatar is at the bottom right
- the activity widget is at the bottom left (in last position if
there are other elements)
==> 'dashboard' kanbans
- the record is accessed through a 'Configuration' option in the card dropdown
- there is no global click, and therefore no focus shadow
- the dropdown icon (o_kanban_manage_toggle_button) is always visible,
with icon fa-ellipsis-v
- the listview counterpart should be presented as a dedicated
configuration menu, and shouldn't be in the 'dashboard action'
- links in the body of the card are structured as follows: link with
<count>+label, then any additional aggregated metrics (not link) to the right
example https://drive.google.com/file/d/1ZP6HDHTtC7cQ6rDWgqLoPs6U8JCeNVkW/view?usp=sharing
==> global guidelines
- the title font color is #212529, with 500 weight
- the subtitle font color is #666666, with 400 weight
- the font size is 1.083rem
- text overflow is handled through linebreak, not ellipsis
- numerical values are aligned to the right
- the kanban state widget is at the bottom right
SPECIFICATION
=================
AS per guidelines Improved follwing kanban/dashbaord view
- hr_job
- hr_department
- hr_work_entry
- hr_appraisal
- fleet_vehicle
- product_template
- sale_subscription_template
- crm_team
- res_partner
- event
- stock_picking_type
- mrp_eco_type
- maintenance_team
- quality_alert_team
- account_journal
Added the department menu on employee with default kanban view
Added sequence in hr_work_entry list view
TaskID: 2206372
Related Enterprise PR: https://github.com/odoo/enterprise/pull/10341Closes: #50536
Allow groups_id on top level view as a way to relax the access of some
views
There was some scenarios where ir.ui.view were still needed to be
accessible.
For instance the website.snippet is needed to display the website
editor sidebar to designers. The website.compiled_assets_wysiwyg is
needed to display the app switcher on the website to employees.
This should cover most of the cases where a view still must be
accessible and no specific controller is available.
render, render_template, load, activity_schedule_with_view,
get_website_pages should all be private:
It should not be possible to render an aribtrary template only with
its name or id
Still need to render some qweb views from js so the method
render_template is kept public.
This explains why the website editor still need read access on
ir.ui.view as we want to allow any snippet to be rendered.
The method fields_view_get should be the only way to retrieve the view
content. This method is executed in a super-user context.
To avoid retrieving views for a model a user does not have access to
(as it may reveal some informations like name of fields), add a
verification of 'read' rights before retrieving the view content.
Execute _postprocess_access_rights with sudo(False) as this method is
used to evaluate which buttons should be displayed.
Remove the su flag to avoid misleading the user and displaying a
button they won't be able to use.
Retrieving the database id from an view key is not considered as a
sensitive information and get_view_id and viewref can be left as a
public methods.
Add missing sudo when needed
Change _handle_visibility in website to avoid increasing the query
count: Checking the visibility (to fail most of the time) to retry in
sudo was making unecessary queries.
Only system users should be able to access directly ir.ui.view records
Other users should use helper methods like fields_view_get or render
to interact with view records (or use sudo)
Give read access to views to publisher
He needs to call read_template on some views like
'web_editor.colorpicker' in edition mode
Restrict ACL on website.page
Apply the same ACL than on ir.ui.view as the model inherits from it.
Give access to designer to modify views
Currently, scheduled Actions only work if you choose "Python Code" as
the action type ("Action To Do"). Other action types are not really
supported as they work "record-wise" (using active_ids) which makes no
sense for scheduled actions.
We should help users avoid surprises by hiding the "Action To Do" field
on scheduled actions, and default to "Python Code" implicitly.
Example steps to reproduce :
- go to scheduled actions > create a new action
- select "Execute several actions" as action to do
- add several actions to execute
- run this action
=> the sub-actions were not executed
opw-2227082
closesodoo/odoo#51242
X-original-commit: b19c7c54efceb780806d876efc65a8813e3491d1
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
- Activate Studio from dashboard of database A
- Export studio customizations
- Activate Studio from dashboard of database B
- Import studio customizations previously exported
The imported data don't have the boolean studio field set to True.
Since v12, when loading a module, a query is executed to create or update XML ids.
The create and write methods are not called anymore.
Therefore the overridden create and write methods of "ir.model.data" defined in Studio module
are not called and thus cannot set the studio field to True.
The generation of the query creating XML ids has been moved to a private method
allowing another module like Studio to override it.
opw-2245578
closesodoo/odoo#51203
X-original-commit: 198ab837e466f3155ea1c3b35811b981b1c1e537
Related: odoo/enterprise#10586
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Let field F of model M be a Selection field.
Before this commit, creating a database with field F, removing/renaming
field F by changing its definition within the code then upgrading the
database to reflect the changes would result in a registry crash because
the field would still exist in the database but not in the ORM (memory),
thus trying to fetch the field in DB from the memory would result in a
KeyError.
This is due to the fact that field renames / removals are not stable
operations and should be handled with a migration script when upgrading
an existing database, nevertheless this can be quite an annoying
behavior while developing which is why this commit simply skips the
processing of the field if it does not exist in memory.
The ORM already foresees these cases and logs a warning to the developer
saying that the field was deleted anyway but that it was only a
partial delete and that it should be handled in a migration script in
order for the change to be production ready.
closesodoo/odoo#51099
X-original-commit: a54fecc35386f8e00018ff3d858b383d43f1dded
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
use alternatively symbol of singapore dollar also set symbol before the amount
task-2187155
closesodoo/odoo#51093
X-original-commit: a15027cb6c64bac10334ecc587a74224d946d9c3
Related: odoo/enterprise#10541
Signed-off-by: Josse Colpaert <jco@openerp.com>
Address format and vat label are not properly set for Austria and
country states are missing for localized needs.
closesodoo/odoo#51038
X-original-commit: 5f05e2f83a9ceebed1dac04ad9fd9f1791738c31
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
The following loop crashes on the second iteration:
for record in records:
record.display_name # access non-stored computed field
record.unlink() # delete record
The cache has been invalidated by `unlink` on the first iteration, so
the field is computed. The computation is done on the whole recordset,
which fails with a `MissingError` because of the first record. The fix
is to retry the recomputation on the single record in this case.
closesodoo/odoo#50910
X-original-commit: 7f33ebf528b1415452ce549e3329c3fe89be0ad8
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Since a required field can not be empty: a warning message will
be thrown if a many2one required field has the "on_delete"
attribute set to "Set NULL".
Task ID 2250533
closesodoo/odoo#50751
X-original-commit: 084555c6395b484a85ec9d386fbc8afc8aec1f8c
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
This commit introduces several changes in the search panel with
respect to record counts:
- the record counts are now also available for
the fields with select="one" attribute
(if not disabled explicitely).
- the record counts are better computed using the idea that
selected values within a group should not impact the counts
for the group values but only the counts for the other
group values.
On the way we have changed two keys in the values returned
by the server:
- 'count' becomes '__count'.
It has been done to avoid a possible clash in case a model would
have a field named 'count' and that the field values would be
wanted for some reason.
- 'name' (multi case) becomes 'display_name'.
It has been done in order to make the select one and multi cases
more similar and factorize some code.
TASK-ID: 2166814
Co-authored-by: Raphaël Collet <rco@openerp.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Alexis Lacroix <laa@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
It has been a recurrent request from customers to be able to send email
messages to email addresses containing non-ascii characters. [IDNA] is a
domain extension to allow unicode characters in domain names. [SMTPUTF8]
is a SMTP extension to allow unicode in any header.
IDNA defines the [punycode] encoding which translates unicode to an
ascii representation. This encoding MUST be used to encode domains.
SMTPUTF8 is an SMTP extension that allow utf-8 in all headers on the
envelope.
[IDNA] https://tools.ietf.org/html/rfc5890
[SMTPUTF8] https://tools.ietf.org/html/rfc6531
[punycode] https://tools.ietf.org/html/rfc3492
Task: 2116928
opw-2229906
opw-2248251
closesodoo/odoo#47709
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
This commit adapts several views to make them use newly defined
widgets, the new decoration-xxx mechanism on fields, and to adapt
them to the new design of buttons.
Part of task 2195254
In list views, one can specify decoration-XXX attributes on the
arch root node. Those decorations are evaluated for each record,
and the corresponding style is applied on rows for which the
condition is true.
This commit allows to specify those decoration-XXX attributes on
field nodes as well. In this case, when the condition is met by a
record, only the field on which the attribute is set will be
impacted.
Part of task 2195254
If an action has for instance twice "tree" in view_mode, you get a crash
when displaying the action.
This patch adds a python constraint on the model which will prevent such
change.
closes odoo/odoo#50189
Opw: #2241415
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
An attribute 'disable_counters' on fields of the search panel is
supported in case performance issues would be encountered with counters.
The commit dd7022eccd
allowing to use the search panel in other views than the kanban views
has also introduced the search panel arch validation
and the attribute 'disable_counters' was forgotten, so that it was
impossible to use it in practice.
With the present commit, 'disable_counters' is now recognized
as a valide attribute.
closesodoo/odoo#50542
X-original-commit: 4c321d0bcb83286c473a6e6c2b622274fa764393
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
1. Create an invoice and upload a picture file as the only attachment
2. Try to print "origin bill" for the invoice (From the invoice tree
view select one and click print > origin bill )
An error will raise "PIL.PdfParser.PdfFormatError: trailer end not found".
Fixing by using another BytesIO object as the output.
opw-2244625
closesodoo/odoo#50469
X-original-commit: 378551193d8199cfab13b06a48aa706f420a7823
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
When computing the `arch` from the arch_db, the field gets translated
as a matter of course as `arch_db` is a stored field with a
translation method. This means `arch` is assumed to be in the proper
language in the cache.
However when reading from the filesystem (dev=xml) this is not the
case, and the view XML ends up untranslated.
Fix the issue by applying the translation function from arch_db onto
the stuff we got from the filesystem.
Note: under the assumption that we *do not* want to store translated
archs in arch_db, explicitly set the lang to None when resetting
views.
Task 2059557
closesodoo/odoo#50389
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Cache should be invalidated when updating `arch_db` via `arch`.
closesodoo/odoo#50512
X-original-commit: 1a14ca163ee256eb26661c900227db49426ec3af
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Revision on 7ecae33571
Commit above introduced activity widget on partner kanban, but
unintentionally affected style of all other kanban views that have
details on kanban record.
This commit fixes the issue by applying special CSS rule only on
partner kanban view, so that other kanban views remain unaffected.
Task-Id 2237638
closesodoo/odoo#50474
X-original-commit: b0ef12bc0bcdb29ffc7e61f1a1a185248650283c
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
ref() always trigger a database query to verify record still exists.
In frequently used methods, it's best to avoid ref calls if not needed:
* either the records should always exist
* either the record isn't always needed and the ref can be sometimes
avoided.
X-original-commit: c1e05da7b71c8274aff00d67f8d1bc7e209fcaab
Steps to reproduce:
- Create a second company
- Enable this company only
- Create a new company
=> Access error is raised because the `intercompany_user_id` is
OdooBot by default and OdooBot's partner cannot be read from
other companies. Hence, the company creation fails.
Like all other internal users/partners, OdooBot's partner should
be shared across companies, even if its user is inactive.
Task 2157039
See also 2390ba6
Task 2157039
closesodoo/odoo#50372
X-original-commit: 379d14d4aa7862176fb7e3f79292a1228c254aa9
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: lul-odoo <LucasLefevre@users.noreply.github.com>
Commit 8c1bb22ec0222dca652e0649454b986c06cb1368 forgot to take into
account migrations, during a migration it is possible that some modules
need to be uninstalled because the target version may have removed /
moved them and since during a migration all modules are set `to
upgrade`, the previous condition made this impossible for migration
scripts that use the ORM for module uninstalls (not Odoo's case, mind
you)
With this commit it is again possible to uninstall modules from a
migration script during a migration.
closesodoo/odoo#50322
X-original-commit: a7c90a6d080a77316924cec9d3c64f9662ac7436
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
Purpose
=======
For a tag to be displayed on a kanban card, it needs to have a color set.
We won't be changing that behaviour, since it would mean having
two options > the color, and whether or not to show it in the kanban
The purpose of this task is to set a color on new tags to make the user
save a bit more time, set a color for him as he might not find the feature,
and make sure the tag will be on the kanban cards.
Specification
=============
For each of the following models, at creation, set a random integer between
1 and 11 in field 'color'
Models:
res.partner.category
crm.tag
project.tags
hr.applicant.category
helpdesk.tag
hr.employee.category
event.track.tag
mrp.eco.tag
repair.tags
closesodoo/odoo#49967
Taskid: 2234527
Related: odoo/enterprise#10112
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
The population of res users was emptying the list of populated partner
ids.
The lunch.supplier population was crashing because no partner id was
present in the partner population registry to use as `partner_id` for
the generated lunch suppliers.
closesodoo/odoo#50266
X-original-commit: a2adc346906ee753df6d8e49caa4ee5381629695
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Http routing and websits module will already do it later and handle the case.
The only ModelConverter used that will be impacted is:
/web_editor/attachment/<model("ir.attachment"):attachment>
that is a json controller called with eisting data
task-2211013
Co-authored-by: Romain Derie <rde@odoo.com>
Co-authored-by: Jeremy Kersten <jke@odoo.com>
Followup fix of #48912
The multi-company group should be given to users if they have access to
multiple companies and do not already have this group.
closesodoo/odoo#50233
X-original-commit: 0c721d90c5cd428ef8d51f195da8e02ee91d4364
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Prevent unexpected country creation when creating a state. Indeed,
there is usually no reason to create a new country.
opw-2239697
closesodoo/odoo#50210
X-original-commit: a502a404b18a0946d9ff64de9e05c28737e82c57
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Instead of triggering one has_group by user (one sql query/user if not already ormcached),
and potentially filling the `has_group` cache with new users data (we don't know if and when this data
will be used anyway), compute this field from the groups information already in cache.
X-original-commit: d771d7e9c8503543d29fdbf2ab961c2a32cc3bac
Improve the performance of the default method for user groups by avoiding a `ref` call,
using the group in cache instead.
Calls to ref always trigger one SQL query to verify record still exists
This means that creating 10k user would trigger 10k queries only for the default.
X-original-commit: e67efb88338ef669059591728e7722fe1dff4bf0
The main classes of partners and users support batch creation, but
the majority of their overrides doesn't support creation in batch.
Adapting those overrides to support records creation in batch shows
great performance gains:
* On `res_partner` : 2 to 3 times faster
* On `res_users`, with the inherited `res_partner` created in batch:
up to 10 times faster.
Tests done with 500 to 4k records:
* `res_partner` with only a name provided
* `res_users` with a name and login
X-original-commit: 9c3c5f161580039c1fe50f68acac808c18817997
Added country states for 6 EU countries: Estonia, Latvia, Lithuania,
Finland, Sweden, Norway. used ISO 3166-2:EE, ISO 3166-2:LV, ISO
3166-2:LT, ISO 3166-2:FI, ISO 3166-2:SE, ISO 3166-2:NO
The county structure in Norway changed on 1 January 2020, but not yet
published in ISO 3166-2
NB! Import for field country_id:id with value "no" for Norway do not
work, must be "base.no", otherwise considered as False
closesodoo/odoo#50168
X-original-commit: 882fa61fd3c3e0e332fb62ecb92a6c4416864321
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
When creating new translations, do not prepopulate the translation
with src.
Take the following scenario:
- set a value in a translatable field in English
- open the translation popup -> creates all ir.translation
- notice an error in English, close the popup
- correct the error in English
- reopen the popup -> existing translations not modified
Add test about reseting
closesodoo/odoo#50147
X-original-commit: 619eccc7a533eedfb3aec0c3740ead1006e0f2f7
Related: odoo/enterprise#10194
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
A plaintext email is displayed in a `<pre/>` tag to conserve spacing.
But since there is no escaping, if in this text there was XML tags or
HTML entities, they would appear as HTML in browser which is not wanted.
Do note that this was not a security issue since the content will still
be subjected to the checks and foundling of HTML emails.
Without the change, the added test would fail because character &,<,>
were not escaped.
opw-2242323
closes#50003closesodoo/odoo#50123
X-original-commit: 932532b5b59e0b71c8e16dadfb2ff36c38764208
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
With this commit, module operations such as install, upgrades and
uninstalls are henceforth forbidden inside unit tests and instead such
tests must be performed with standalone Odoo scripts.
This is done because module operations during tests are not
transactional, this can leave the registry in an unclean state and
further tests may be affected by this, it also creates a new registry
which complicates registry cleanup if anything crashes,
because the registry to be cleaned up is not the same one that crashed.
Instead, what should be done is a script that imports odoo as a library,
and loads the database necessary then performs whichever operations
necessary. This script should contain a single function with a single
parameter (env) and should be decorated with
@odoo.tests.common.standalone in order to be executed properly, this
decorator accepts any amount of positional parameters as tags that can
be specified when calling the script in order to execute only a select
subset of scripts.
Special tags are: 'all' and <module_name>, these are generated
automatically, the first will execute ALL scripts available whereas
<module_name> will execute all scripts introduced by said module.
When calling the test_module_operations script, only scripts found in
*installed* modules will be executed, script discovery is only possible
if the code is loaded therefore it is only possible if the module is
installed.
closesodoo/odoo#49669
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
- Create 2 companies C1 and C2
- Install any module with access rules, e.g. `account`
- Create an invoice in C1, attach a document
- Switch to C2
- Go to Settings > Technical > Attachments
An `AccessError` is raised.
This happens because the `_search` skips the ACL and record rules for a
system user, while they should only be skipped for the superuser.
opw-2236561
closesodoo/odoo#50067
X-original-commit: 9a71d60c25804bc4bae8c2c680c537f8a7a0900f
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
When a user is linked to a contact, the type should not be
modified. Otherwise, the res.partner type may become incompatible with
the res.user record (e.g. is set as a private address and a user no
longer has access to its own user)
Fixesodoo/odoo#48177closesodoo/odoo#48590
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Werkzeug 1.0 adds a `merge_slashes` feature which calls rule.build()
*during match*[0] (= during dispatch).
However at this point our environment still contains an invalid /
placeholder UID, so `display_name` / `name_get()` fails dramatically.
One possibility would be to update the slugifying to not access the
record (outside of the id) if the environment is not "proper", an
other alternative is to just disable the feature since it seems to not
have been necessary so far.
The latter seems less hacky so do that for now, we can always swap the
solution later if we need to.
[0] https://github.com/pallets/werkzeug/blame/048cdfd9b969c0c3a133d7ff43b8ad1ad6a673ec/src/werkzeug/routing.py#L904
It is now possible not to format integers according to locale
This is particularly interesting and relevant when a number holds
some sort of code rather than a number
Task 2050119
*: base, fetchmail, l10n_cl
closesodoo/odoo#39767
Related: odoo/enterprise#6964
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Set a default email signature to an empty string to avoid `False` when
evaluating `${user.signature | safe}` in email templates.
opw-2229846
closesodoo/odoo#49558
X-original-commit: 96f46fba2635d8050aef03c7d4744a87ac8a597e
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Also non-browser jsonrpc (as it goes through a similar process): for
internal performance reasons, name_search and read_group have been
converted to a *lazy* name_get, so the "display name" is not
unnecessarily computed.
However this is an issue for the RPC endpoints (/xmlrpc and /jsonrpc)
as they have no support for `lazy` and thus tend to blow up and / or
do the wrong thing when trying to output a lazy:
* xmlrpc has no way to handle lazy at all and straight blows up
* jsonrpc falls back to `json_default` so they try to stringify the
lazy, which might have worked except
*Problematically* both endpoints delegate the actual work to
`dispatch_rpc` which handles dispatching between various services and
ultimately creates a *new* cursor before calling model
methods (`object` service and `execute`/`execute_kw`).
This means by the time the result is serialized to be output, the
lazy's cursor has long been closed, and thus any access to an
unevaluated `lazy` errors out when trying to fetch the underlying
item.
This also means we can't just add a hook to serialize the lazy
in the xmlrpc marshaller, though we do have to do that. We *also* (for
both xmlrpc and jsonrpc) have to force evluation of lazy values before
our cursor is closed, meaning it has to be done right after the method
is invoked, iterating the entire response.
Related to task 2170343
closesodoo/odoo#49286
X-original-commit: e2b5a359c1d5eccbe725c1c3169b4130d7bca49b
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Currently, sometimes users are getting confusing between the concepts
of 'objects' and 'models' when doing advanced configuration or
customization.
So, In this commit we replace 'object' label by 'model'.And also add
quicksearch on the relation field.
TaskId: 2209594
Related Ent PR: https://github.com/odoo/enterprise/pull/9556
closes odoo/odoo#48647
Closes: #48647
Related: odoo/enterprise#9556
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
jvm-odoo