Have an x2many with an x2many editable list inside the form view
containing at least a row. Open a record, click discard. Open it
again, and click on a row of the x2many to switch it to edit mode.
Before this commit, the row could never be switched back to
readonly. This was the list renderer didn't correctly compute its
active element (it must wait for a micro tick for the mounted hook
of the dialog, its ancestor, to be called).
After fixing this issue, a second one arise: the row can now be
unselected, but it disappears if it is a new record. This is
because we lost the dirty flag when clicking on discard. This is
fixed by storing the dirty state alongside changes in the
savepoint.
Part-of: odoo/odoo#114024
Before this commit, x2m in list mode with several pages did not work
correctly when sorted. The order was lost when the page was changed and
any values not used for sorting were missing.
How to reproduce:
- Go to a form view with an x2m in list mode with at least 2 pages
- Sort on a column
- At least one record not present before sorting is displayed
Before this commit:
This record only contains the values used for sorting
After this commit:
This record contains all the values
- Click on next page
Before this commit:
The records displayed on the page are not ordered and contain only
the values used for sorting.
After this commit:
The records displayed are the correct ones for the sort and contain
all the values.
Part-of: odoo/odoo#114024
Before this commit, go to a form view with an x2m displayed in list mode.
If you sort the x2m on two differents fields, a crash is displayed.
How to reproduce:
- Go to a form view with an x2m in list mode with at least 2 columns sortable.
- Click on a column to order
- Click on a second column to order
Before this commit:
We have a crash
After this commit:
The list is ordered correctly
Part-of: odoo/odoo#114024
This commit adapts the code in addons w.r.t. the introduction of
the RelationalModel.
Main changes that were requested are:
- record datapoints no longer always have an "id" key in their
data (they still do if the id field is in the view), so we use
record.resId instead
- the new model is based on fined-grained reactivity, so several
components that previously relied on onWillUpdateProps to update
their internal state no longer worked. Typically, using the hook
"observeRecord" is the way to go now.
- specialdata are no longer handled in the model, so the components
needing specialData can use the hook "useSpecialData"
- more generally, all overrides of models (RelationalModel or
KanbanModel) needed to be reworked.
Part of task~3179751
Part-of: odoo/odoo#114024
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: FrancoisGe <fge@odoo.com>
Co-authored-by: Jorge Pinna Puissant <jpp@odoo.com>
Co-authored-by: Pierre Rousseau <pro@odoo.com>
Before this commit, we had several implementations of a relational
model. The form view used the BasicRelationalModel, which was a
wrapper around the BasicModel. The list view used the
RelationalModel (a simpler version that didn't support complex
usecases of x2many fields). The kanban view used the KanbanModel,
an extension of RelationalModel.
This commit removes all these, and replaces them by a single model.
It is called RelationalModel, and as a similar structure as its
predecessor (with datapoints). It now handles tricky x2many usecases
of the form view though.
This commit also comes with several important changes:
1) The new model is based on unity reads [1]. This means that all
data required by the view is fetched at once, and datapoints are
created with their data (whereas before, they were responsible to
fetch their data). There's an exception for special data: they are
no longer handler by the model. A hook "useSpecialData" has been
created, and it allows fields (components) to fetch additional
data they require.
2) The new model uses onchange2 [2]. With onchange2, we send and
receive a diff, instead of the whole state of the record. Morever,
onchange2 uses unity, which means that returned commands for x2manys
(e.g. command 4, LINK) contain the values of the corresponding
records, so we don't need to fetch them in a separate call
afterwards.
3) The new model no longer triggers deep renderings (render(true)).
It is instead based on fine-grained reactivity (i.e. only what
depends on what has changed is re-rendered). We introduced a hook
"observeRecord" which allows a component to subscribe itself to
some keys in a record datapoint, and register a callback to
execute when those keys change (e.g. to fetch data).
[1] odoo/odoo@7d2baaa0c7
[2] odoo/odoo@f5e6494da3
Task~3179751
Part-of: odoo/odoo#114024
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: FrancoisGe <fge@odoo.com>
Co-authored-by: Jorge Pinna Puissant <jpp@odoo.com>
Co-authored-by: Pierre Rousseau <pro@odoo.com>
This completes 96a98f4f4c in the case
where a many2one field has a new record as value, even when that
many2one field is not a delegate field.
Part-of: odoo/odoo#114024
This commit improves the selection of records in list view using the
SHIFT and arrow keys. In task 2039894, it has been made possible to
select a range of records using the keyboard, but the experience was
confusing. So, the latest task aims to improve the situation regarding
selection with keyboard and navigation.
A test has been added to verify the behavior when selecting multiple
rows, using multiple ways of interaction (SHIFT + arrow, click,
navigate and select).
task-3418715
closesodoo/odoo#128995
Signed-off-by: Florent Dardenne (dafl) <dafl@odoo.com>
The dark mode assets were mistakenly loaded in the default backend
assets, effectively overriding the light theme for spreadsheet 100% of
the time.
closesodoo/odoo#129339
X-original-commit: 97cf8bf7f757b82bdecd6a4531d6b00fcd591bd9
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
If a user goes from "Access Rights" (base.group_erp_manager) to
"Settings" (base.group_system) he gets an error telling him he did not
belong to Access Rights group.
The reason was that the modification of accesses on the user profile
page was doing
write({'sel_groups_2_4': 4})
which was transled, after the _remove_reified_group call into
write({'groups_id':[(UNLINK, [2, 4]), (LINK, [4]]})
so the user was temporary in a state where he was in the group_system
but no in group_erp_manager.
When the implied groups where computed, an access error was raised as
the administrator was not allowed to modify res.users record (need
group_erp_manager).
Simplify the _remove_reified_group call to only convert the call to
write({'groups_id':[(LINK, [4])]})
closesodoo/odoo#129335
Task-id: 3265053
X-original-commit: 0ed2fa018a7716f0fb3abe587983209403445fc8
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
This commit is part of the refactoring and improvement of the html and css of account_reports (enterprise).
Here we:
- Remove blank_if_zero default value of True, it is now False by default. The zeros are now shown in a muted gray color.
- As we had a level of hierarchy 0 that allows for some further styling we needed to adapt _compute_hierarchy_level to take it into account when calculating the increase level. So if the level is 0 or 1, the child will have a level of 3 either way.
- Removed some UPPERCASE column styling.
Task-id 3251726
closesodoo/odoo#129232
X-original-commit: 56a7f7745c5df9b70e6fe5b78f401085ce46284c
Related: odoo/enterprise#44436
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
before this commit, in the import module wizard the
end user can select any type of file in the upload
file field and clicking import it will say only zip
format is supported.
after this commit, on clicking upload files, only
zip files will be shown to the end user to select,
which will make easy to select the files from
directory
closesodoo/odoo#128484
Related: odoo/enterprise#44089
Signed-off-by: Luca Vitali (luvi) <luvi@odoo.com>
We currently convert rgb colors to hexadecimal, but not rgba colors.
Unfortunately since many Bootstrap border colors are defined as rgba,
this meant that these were not properly converted for Outlook (which
doesn't support rgba).
To convert rgba while losing the transparency information we need to
"flatten" it by taking in consideration the background color.
closesodoo/odoo#129153
X-original-commit: dc56506cffa5a13508ca24018d4f0a25c5353cca
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
The `font-family` style can sometimes include double quotes. This isn't
really a problem since these get escaped (`"`) but emailonacid
currently has a bug where the double quotes cause every subsequent style
to be ignored, and the rendering to be incorrect. For the sake of future
testing, this converts them to single quotes. It also removes the style
entirely from image elements since they don't make sense there.
X-original-commit: 03c7e69db63f326c7a3b3085debc5d3a5c95966d
Part-of: odoo/odoo#129153
A semi-colon unfortunately took the place of a double pipe in code that
retrieves an image's width in order to set its width attribute. This led
to some images being wrongly sized.
opw-3299392
X-original-commit: 0a21da39f05ef9ec9d202424e0e648849f44e164
Part-of: odoo/odoo#129153
Customer reported an XML file with an UBL_version 2.2
reported <cbc:UBLVersionID>2.2</cbc:UBLVersionID>
at the beginning of the XML file.
As reported on the wikipedia page of the
'Universal Business Language' (UBL):
- the version 2.2 has been approved&published on July 2018.
- the version 2.3 has been approved&published on June 2021.
opw-3316684
closesodoo/odoo#129043
X-original-commit: 5b011440eb96ab02aaaa3b3754d0475a01a2ef16
Signed-off-by: Baptiste Vergote (bve) <bve@odoo.com>
Steps to reproduce
==================
- Go to documents
- Click on a document
- Add a tag
-> Nothing happens
Cause of the issue
==================
Since https://github.com/odoo/enterprise/commit/e35017719d0996279f362423a7b4b1c6e30b9766 ,
the documents app uses the _multiSave method from the relational_model.
If the selection is of only one record, the changes passed to the method
are ignored.
opw-3393862
closesodoo/odoo#128515
X-original-commit: 7e361761d20ddc64c62b85f3496e1596dc42987b
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
This commit remove the way we display the price on the same line as the product name.
It was only used in few cases and most of the time the price was display on another line because we have to add information.
So now, we just use only one generic case that can handle all of them.
closesodoo/odoo#127575
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Complement to commits:
290465e57dfcb8503e382a418e0ba4498ea5693b
72c62dbf157dfb353caf13a228921e3f81036885
Prevent synchronization between applicant
and partner if partner information changes.
The partner must be changed to update the applicant.
When someone applies for a job via a platform,
the "generic" email is used to create the applicant.
As a result, all applicants have the same partner.
The different commits and this one ensure that
the partner's email is not overwritten
if we update the applicant's email address.
Because changing the partner's email address
synchronized it with all applicants.
All applicants had the same e-mail address.
opw-3166630
closesodoo/odoo#129277
X-original-commit: 397e5ee79b46631040eb71c89b1f7e2891a3da52
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Signed-off-by: Thomas Lefebvre (thle) <thle@odoo.com>
Fix various issues that appeared when working with registrations. When converting
registrations to leads using rules some convert flows have issues or can crash. This
PR fixes several issues, see sub commits for more explanations.
Improve test suite to cover more use cases.
Task-3431124
closesodoo/odoo#129269
Forward-port-of: odoo/odoo#129111
Forward-port-of: odoo/odoo#128823
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Avoid issues when generating lead description based on linked registrations
notably with formatted emails.
Task-3431124
X-original-commit: 471025a7bd227d334ac5b450c93a2ee99c22517a
Part-of: odoo/odoo#129269
Partial backport of odoo/odoo@94fa8d9625 keeping only event_crm part as
other changes were done only for Odoo16.
In this commit we try to compare formatted phones of registration and
partner, before checking the actual phone numbers. If only formatting
differs then it is not a different number.
Task-3431124
X-original-commit: 4589eebe4978ac0746fa4bc5c8664cb30d912cc1
Part-of: odoo/odoo#129269
When checking updated values of a registration to propagate to its linked lead
we may compare a recordset to IDs. This commit fixes that by always comparing
IDs.
Task-3431124
X-original-commit: 874c2cf44c9f42d928b646c86c974251dd95cfc0
Part-of: odoo/odoo#129269
Co-authored-by: Jeremy Hennecart <jeh@odoo.com>
When checking if partner and registration have the same email, better compare
normalized versions if possible as it filters out formatting differences
e.g. if one input has a formatted email with another name.
Task-3431124
X-original-commit: 1f2a08e6b0880d20f877a73badd3b071939bcc13
Part-of: odoo/odoo#129269
When having rules creating leads from registrations, email and phone are
copied from the registration if the linked partner has no value for those
fields. However an error in the code lead to setting phone into email which
is not really correct.
This commit also add tests for event_crm who allowed to spot other issues
which are fixed in the next commits.
Task-3431124
X-original-commit: 9bbf621e8e9cda90a0d29fd44e21cd4b61a54d73
Part-of: odoo/odoo#129269
To reproduce
============
on journal items add filter (Analytic contains something) and group by Account, no lines will be shown.
Problem
=======
`analytic_distribution` is a Json field stored as string in database as follows: `{"id" : "percentage"}`, which explains why no result is returned as there is no trace for Analytics name.
Solution
========
following same [fix](https://github.com/odoo/odoo/commit/bc5b72937a1c79688f7f6dc1c8aeaa7eb4cb6744), we replace `analytic_distribution` by `analytic_distribution_search` in the domain of `read_group`.
opw-3391182
closesodoo/odoo#129263
X-original-commit: 05209fd295727cbbb5bf6a316f3c8873de6b2bed
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Abdelouahab Laaroussi (abla) <abla@odoo.com>
Since [this commit], when the user configures a new website, he can
set an unknown industry. Unfortunately, if he does so, by default, we
set the industry to abbey, which is not very good for the default images
the user will see and for internal IAP stats. This commit permits to use
the new industry called Unknown, which is used for unidentified
industries. When the industry is unknown, we leave the default theme
images.
[this commit]: https://github.com/odoo/odoo/commit/e82a1cb2ef1bcb413d99e7eb7521405d1d2e88d2
IAP PR: https://github.com/odoo/iap-apps/pull/635
task-3337894
closesodoo/odoo#129154
X-original-commit: 17dd3a84d9d9d42b04fde9aac708c032a472b13b
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
Before this commit:
When changing the tag name, e.g applying a new format, the other styles
applied are removed
After this commit:
We no longer remove already applied styles of the text and only change
the tag name
Reproduction:
1. Install Email Marketing, create an email with a template
2. Drag a text block and set the background color of the whole block as
yellow
3. Set one line of the text body as Header 1, the background color is
cleared
Reason: it’s a normal result of removeFormat, it clears the background
color of the parent element and re-apply the color to the text not
selected
Fix: After checking a few most popular editors, the common behavior is
to keep the other styles applied to the text and only change the tag.
Thus this fix will remove the format removing steps. Because of this
change, the test case to check if the gradient text background color is
modified. Other specified styles are kept after the tag change.
Note: If the background color is the 5 colors at the first row, it won’t
be cleared by setting the format because the color is set as a CSS class
task-3245698
opw-3165587
Related PR/Fix:
Adding the gradient background color removal
https://github.com/odoo/odoo/pull/83065closesodoo/odoo#129285
X-original-commit: 17f90e304537e517233b8762d4fd2b7f75bfa642
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Purpose:
--------
Currently, a crash occurs if a portal user tries to open the colorpicker
(for example in project_sharing, or in knowledge portal introduced in
16.3 [1]).
This commit fixes this by adding the group `base.group_portal` to the
groups of the colopicker template.
Task-3429053
[1] https://github.com/odoo/enterprise/commit/1badfeae8d5c93c8bba8dafd56f94f6433888590closesodoo/odoo#129274
X-original-commit: 94e3211aa84feab28ac03902d9af849967ab125c
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Steps to reproduce:
-------------------
- being in a multi-company context;
- select a company that is not the user's default company;
- add a manager to an employee;
Issue:
------
We don't see the organization chart.
Cause:
------
There is no "allowed_company_ids" key
in the context of the rpc call.
Solution:
---------
If a context is passed explicitly
in the call rpc kwargs, it must be used.
Otherwise, use the default context of call rpc.
opw-3422642
closesodoo/odoo#129233
X-original-commit: 32353bcf94fa4f7378f61c22664267e1e8a34a1f
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Signed-off-by: Thomas Lefebvre (thle) <thle@odoo.com>
In saas~16.3 the field `tax_audit` was removed from the account_move_line model.
This PR is to remove an update to that field from a localization upgrade script since it doesn't exist anymore.
PR where the field was removed: https://github.com/odoo/odoo/pull/114616closesodoo/odoo#129246
X-original-commit: 041c68ea7b40dfad124f19d04498783da3b53a91
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Current behavior:
When the currency in the PoS is not the same currency as the one of the
company, and uses a big rates there are sometimes rounding issues. These
rounding issues can lead to a difference at closing that prevent you
from closing the PoS session.
Steps to reproduce:
- Make sure atleast 2 currencies are activated. (USD and EUR)
- Modify the USD rounding factor to 0.000001
- Modify the rate for the EUR to 2100 Unit/USD
- Now go in the PoS settings and go in the Default Journals Order and
set the currency to EUR
- Change the pricelist currency to EUR
- Change the cash payment method journal currency to EUR and remove
other payment methods
- Open a PoS session and create a new order with 3 products with a
price that has decimals
- Pay the order with cash
- Close the session, you will get an error
The error was happening because the rounding was done on each line and
therefore we were losing precision.
opw-3258806
closesodoo/odoo#129241
X-original-commit: 112e224ace6e658c563d6041532e133ddcc1c8a7
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Robin Engels (roen) <roen@odoo.com>
Since the dependency to account_edi has been removed from l10n_mx_edi
and knowing we plan to remove completely the account_edi module and
since it's the single localization needing an EDI on payments, all this
code can be removed.
Task: 3069324
Part-of: odoo/odoo#128395
The logic of the send & print wizard is to generate all EDI documents and PDF at the same time
to ensure the consistency between all business documents.
In some localizations, we need custom references to the generated EDI documents inside the PDF.
The problem is the current PDF engine is not designed to easily extend such PDF template and provide
custom values to render it. Also, you absolutely need an ir.actions.report to use the PDF rendering.
To make such customizations less paintful, this commit adds a hook on the send & print wizard allowing
to provide a custom template inheriting the standard one and custom values for the rendering.
Task: 3069324
Part-of: odoo/odoo#128395
Allow localizations having an EDI to prevent resetting to draft an invoice already
sent to a government. By law, in some countries, if you want to cancel an invoice,
you need to ask an authorization from the government.
Task: 3069324
Part-of: odoo/odoo#128395
Currently, when a user requests a migration key, we set them as 'canceled' and show the migration key.
That means, they won't receive new invoices/invoice status updates.
However, the idea of the migration is that a user should be reachable at all times
and we should receive documents for them up until they are fully migrated to another service.
The solution is to keep `account_peppol_proxy_state` as `active` when they request a migration and display the migration key.
On the IAP side we will check with a cron whether they have migrated or not.
A migrated user is then archived on the IAP side.
That means that whenever we run a cron on the client side, the edi user would not be found,
so the edi user will be archived in `_make_request`.
We can then safely change the `account_peppol_proxy_state` to `not_registered`.
closesodoo/odoo#129166
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Before this commit
==================
Marking an operation as done rather than start and done, the status of
subsequent immediate next linked work orders is not updated properly inside
WO list view.
Steps to Reproduce
==================
- Create a bom product having more than one operations.
- Create a MO and confirm it.
- Inside WO list view select a single first operation of the recently created
MO, and click on done, you will find that the status of subsequent operation
(immediate next) is not updated properly.
This happens because of the reservation state of the MO which has initial
state as false and thus the status of work-order changes to 'waiting'.
With this commit
================
Marking operation as done the status of subsequent linked work order gets
updated properly.
closesodoo/odoo#128881
Task: 3358125
X-original-commit: 0533577264413934179cc32e0cfe26cb324dd58a
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
This commit completes the addition of t-field with a few changes in its
behaviour in the editor:
- t-field nodes, like t-esc or t-out, are considered as unbreakable
- similarly, they are defined as 'demo data' which cannot be edited
closesodoo/odoo#128228
Related: odoo/enterprise#43978
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Have the wysiwyg take an editable from an iframe. At the unmounting of the wysiwyg, save it.
Before this commit, the editable and dirty nodes were not correctly resolved as the JQuery instance
would be the one of the main document.
After this commit, we build a custom jquery function to make sure to search in the relevant document, and
be able to locate nodes even if the iframe's document is not bound to a browsing context.
Part-of: odoo/odoo#128228
Before this commit, when displaying the available conditional branches
on a node, the QWebPlugin's select element only had the name of the attribute.
This commit adds to this name, the actual condition present inside the attribute.
Part-of: odoo/odoo#128228
Before this commit, the option getContextFromParentRect was not used to compute
the position of the branching in the QwebPlugin.
Also, the Wysiwyg forced that callback in the options.
This commit fixes those two issues
Part-of: odoo/odoo#128228
Before this commit it was not possible to print a report without
bypassing the retrieval of a previous attachment, or to print
a report without creating one.
After this commit it is possible with the context key "report_pdf_no_attachment"
Part-of: odoo/odoo#128228
Before this commit, when typing "/" inside a node that had a t-field attrbute
the OdooEditor displayed its hint in order to spawn the Powerbox.
This is not ideal as the content of a t-field is rather irrelevant.
After tis commit, a t-field node behaves like a t-out: there is no hinting inside them
Part-of: odoo/odoo#128228
Before this commit, planning option is view in project
setting.
This commit planning option is move from project to planning setting
with named 'Project Planning'
task-3251687
closesodoo/odoo#125341
Related: odoo/enterprise#42675
Related: odoo/upgrade#4940
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Description of the problem:
When an item in an invoice is not 16% standard VAT rated, the KRA
expects an "Item Code". These "Item Code"s were formerly referred to as
HS Codes, however this was never an accurate description of what they
were, since they never shared in the nomenclature of the Harmonised
System and they refer to services (as opposed to just goods).
Examples of KRA Item Codes:
- 0001.12.00 The exportation of goods (0%)
- 0010.21.00 Tea and coffee brokerage services (exempted)
- 0001.13.14 Natural gas in gaseous state (8%)
The KRA's item code system consists of several components:
- A code, of the format 'XXXX.XX.XX' (where X is a digit [0-9])
- A description explaining the use case of the code
- The tax rate specific to code, this can be interpreted as "using this
code justifies using the tax rate that you have on the invoice line"
There are few conceptual problems with the application of these codes,
since they don't exactly match the way things are approached in Odoo. I
took care in the examples to include the "Exportation of goods" code.
Which should be used to justify all zero-rated taxes on exports. I also
included an example where, for instance, natural gas is rated at 8%.
From the two examples above, it is clear that the code does not relate
directly to the product, which is where the fields are currently
represented. Instead, the relationship is more accurately between the
code and the line that it describes.
However, to avoid putting the code on the line and complicating the
'account.move.line' model further, we can the relationship between the
code and the tax.
This means that for each code the user finds themselves using, there
will have to be a specific tax, for example (with respect to the
examples above):
- "Zero Rated Exports (0%)"
- "Tea/Coffee Brokerage (0%)"
- "Natural gas (8%)"
In this commit:
A new model representing the KRA item codes is added in l10n_ke, along
with a many2one relation to it on the account.tax.template/account.tax
models. Accompanying views for the new l10n.ke.item.code model and the
many2one field on the tax are added.
In l10n_ke/data the item codes themselves are added in csv format.
L10n_ke/security is added, and ir.model.access.csv to describe access
rights for the new l10n.ke.item.code model.
The account tax template is updated to add a default export tax with the
appropriate export item code applied to it.
In l10n_ke_edi_tremol, the move validation and serialisation (in which
invoice data is serialised for sending to the device) is updated to
handle the new schema.
The inheritance of product and the additional item-code related fields
is removed from l10n_ke_edi_tremol as they are no longer required, the
same is true of the associated views.
closesodoo/odoo#112013
Related: odoo/upgrade#4528
Signed-off-by: Josse Colpaert <jco@odoo.com>
Aaron Bohy