In this case for scenario with multi-company, the new line of the reward product, should be set with the taxes for company of the current sale order.
Before this change the taxes that are selected were for the all companies setted in the product.
closesodoo/odoo#68029
X-original-commit: eb6ba44a6bfd0ebfce887edc307e0306765e5183
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Steps to reproduce the bug:
-Create a time-Off request R1 for 27/01
-Refuse R1
-Create another Time-Off request R2 for the same date 27/01
-Set R1 in draft
-Try to delete R1
Bug:
A ValidationError was raised:
You can not set 2 time off that overlaps on the same day for the same employee.
opw:2447540
closesodoo/odoo#68005
X-original-commit: 22db3d4168b61f2904e331ac570a1df4904d9791
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
`_prepare_invoice`
Since a3afb98, the `invoice_line_ids` value is replaced in
`_create_invoice`.
This broke some custom client overrides based on overrides of
`_prepare_invoice`.
This commit brings back the old behavior, ensuring that the
`invoice_line_ids` values
specified by `_prepare_invoice` are extended but not replaced.
closesodoo/odoo#68015
X-original-commit: 9beceb0fd4572bdada30cf4ded235c1ff634083c
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Before this, due to the order the lines were interated on (their sequence), some lines were duplicated without parent, making the duplicate report's layout different from its parent. We now ensure we treat the lines in an order that guarantees the parent line has always been copied before its children.
closesodoo/odoo#68011
X-original-commit: c815342b986851e0a4733ed5bf9fbcc7f8fb7442
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Before this commit it was rather painful/cluncky to find a way to remove this block.
By setting a name on the block we can easily xpath it to replace it or add extra content within.
This makes it easier for external devs to influence this view.
closesodoo/odoo#68010
X-original-commit: d418e4e16a46a0d499e606598b3524eabd19e5fd
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The current behavior was to set the label as memo in the payment register wizard.
However, this is to restrictive when a vendor bill hasn't any payment reference but a bill reference.
In that case, the user is expecting to have the bill 'ref' in the payment 'memo'.
Since the matching rules in the reconciliation widget are matching line.name, then line.move_id.ref and then line.move_id.name, the same logic is applied here to construct the payment 'memo'.
closesodoo/odoo#68004
Opw: 2440389
X-original-commit: 92ceb86d58f4d78c8a4256f29d101d3730517b93
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
The Lunch module can automatically send an email to a supplier with the
daily orders at a configured time. It can also remind the users via chat
so they don't forget to order their sanddwish.
Before, two high frequency cron jobs were responsible to check every 20
and 5 minutes if we reached the moment when to send the email to the
suppliers or the notification to the users. Together the two crons were
executed 360 times a day.
The new model uses a dedicated daily cron per supplier record and per
alert record, the dedicated cron is created on the fly and its moment of
execution automatically updated to reflect the supplier/alert record.
See also #41858 for prior work.
closesodoo/odoo#63749
Task: 2416741
Related: odoo/upgrade#2044
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
It shouldn't be possible to create refunds on misc journals, as the tax report would compute the wrong multiplicator sign, and hence end up being entirely wrong.
Introducing the constraint also allowed finding an issue within _move_autocomplete_invoice_lines_create: some tests directly create an invoice by giving it line_ids instead of using the invoice_line_ids helper. The former implementation of this function made it so that the default type wasn't set in the context properly, and these tests were putting their invoices on misc journals. We fix this here as well.
closesodoo/odoo#67965
X-original-commit: fdc96de0e411760f84a78c36543f9157332346de
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Issue
- Install 'Blogs' module
- Create a blog post
- Set published_date to 01/01/1997
- Go to website
- Edit any page and add a 'Blog Posts' Block
- Set 'Layout' to 'Cards' (or 'Horizontal')
- Save
In snippet cards, the blog post date is not the published date.
Cause
Displaying update date ('write_date' field) instead of
the published date ('post_date' field).
Solution
Replace 'write_date' by 'post_date'.
opw-2443104
closesodoo/odoo#67985
X-original-commit: 681e709b239c2456c71d1c16bb40de055dfb927c
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Client issue: when updating the company of a contact, the Display Name
keeps using the previous company's name, so given Bob in company A, if
Bob is moved to company B the form's title remains "A, Bob" instead of
becoming "B, Bob". More annoying, if Bob is moved back to A the name
becomes "B, Bob".
On res.partner, `display_name` is a stored computed field which
depends on `commercial_company_name` (via `name_get` -> `_get_name` ->
`_get_contact_name`). This is an other stored computed name, which
depends on `commercial_partner_id`, which is yet another stored
computed name, which depends on the `parent_id`.
The dependencies are meh but usually resolve fine, the issue occurs
when a base.automation rule is created with a non-empty
domain (including an empty literal list, which was the case here):
when the first field of the sequence is computed, base.automation's
`_compute_field_value` is called. This calls `_filter_pre`,
which (because `filter_pre_domain` is non-empty) calls `search` on the
model.
This would normally be innocuous as `search` will only flush the
fields used in the search, however for `res.partner` the default
`_order` is... `display_name`. Meaning we flush that computation,
forcing the computation of `commercial_company_name`, but since
`commercial_partner_id` is being computed we reuse its old value (or
something), which is not re-recomputed after the
`commercial_partner_id` computation ends.
So rather than resolve a full search involving an order, filter the
records in-place.
OPW-2427264
closesodoo/odoo#67987
X-original-commit: 221ea6079b2beeb66c4cfa48b237791e1b380c5e
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
To find the main element which scrolls in the page, we rely on its
height being as tall as the body one. The code which checks that was
making a comparison between a rounded value and floating value without
care of the rounding errors that might induce, especially on zoomed
pages.
Fixes https://github.com/odoo/odoo/issues/63306closesodoo/odoo#67986
X-original-commit: 71b6fc7341dfec5e8fc2352c3143b1e324a880f8
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Issue
- Install "Sales"
- Switch to "German" language
- Go to Sales -> Products -> Products
- Try to filter on "Public Price" is equal to "2,3"
Not possible to add decimal point at the end (only in middle of number).
Cause
In case the 'decimal point' in DB params is not a dot '.',
the filter input will be considered as 'text' instead of
'number'.
In case of the 'number' type; HTML do already a pre and post
processing, including managing decimal point (who, for example,
is not included in ev.target.value if last char is a '.').
Unfortunalty, the library is not well working with other
language and not supported on every browser, therefore,
must use own logic.
In case of a 'text' type, the value will be send to 'parseFloat'
,then `parseNumber` will replace decimal_point by dot (also one the
issues since needed to display decimal_point according user language),
and `Number` will remove the decimal_point in case of '123,' -> '123',
and therefore we will not be able to write decimals ( apart of adding
the decimal point after writing the whole number...)
Solution
If user input is well parsed, store parsed value in condition.value and
set condition.displayedValue to the input value (an so without updating
input value). Else, replace input value with previous value (who should
be the condition.DisplayedValue).
opw-2463441
closesodoo/odoo#67978
X-original-commit: e795ce5bff14b6b748c1f4a2651946aafdc299f4
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
When adding a variant product, if the option "Variant Grid Entry" is
enabled, it will reset the delivery date of each purchase order line.
To reproduce the error:
(Use demo data)
1. In Settings, enable "Variant Grid Entry"
2. Create an RfQ
3. Add the field "Delivery Date" to purchase order line view
4. Add a basic product (e.g. "[FURN_6666] Acoustic Bloc Screens")
- Keep its delivery date in mind
5. Add a variant product (e.g. "[E-COM12] Conference Chair (CONFIG)")
Error: The delivery date of the first purchase order line has changed
for no reason. Moreover, suppose that in step 4, the user defines a
specific date: the latter will still be changed after the variant
product is added.
When adding a product, the delivery date of the purchase order and its
lines are recomputed. However, an override of `onchange` ensures that
the new delivery date of the lines will be ignored if the `onchange`
concerns the field `order_line`. Here is the problem: when using the
Variant Grid Entry, the `onchange` concerns the field `grid`. As a
result, the new delivery dates are kept. This explains the creation of
`_must_delete_date_planned` in this fix.
However, when returing the result of an `onchange` linked to `grid`, the
result contains the existing lines (on client side) and the new ones
(from the Variant Grid Entry). If the field `date_planned` of the new
lines is deleted, the client will raise an error when it tries to render
these dates (it has no information about their value). Since existing
lines are of the form `(0, <client_id>, <values>)`, this fix only
deletes `date_planned` field for lines with <client_id> defined.
OPW-2454164
closesodoo/odoo#67972
X-original-commit: d2d495bca3e91862470702f1ef07aa27c33d8e2d
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
Allow creating a journal entry in the past after having changed the
sequence number reset on newer sequences.
opw-2445559
closesodoo/odoo#67963
X-original-commit: 26a43f23ec2b2490aec0731e25568703729581f0
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Signed-off-by: William André (wan) <wan@odoo.com>
odoo/odoo#48362 updated the systems to not show the "Statistics"
section when it's empty, but left an @invisible, leading to not
showing the section at all, ever (which technically does avoid showing
an empty section).
Remove the `invisible` attribute, since the section is now added by
`digest` it should never be hidden. This doesn't fix existing views
tho.
closesodoo/odoo#67964
X-original-commit: 09d8b027e39d1d2eb15abb8d9fe564292fa96d32
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
When syncing Odoo with Google Calendar, if one Odoo event has an
attendee with an email address that contains some uppercases, it will
lead to undesirable behavior.
To reproduce the error:
(Need contacts)
1. Create an event
- In attendees, adds a new partner PA
- The email must be valid and the local-part must contain at
least one uppercase (e.g. demoUP@example.com)
2. Sync with Google
3. On Google Calendar, update the event (e.g., add a description)
4. Refresh Odoo Calendar
Error: The event is updated, but the attendee has been removed.
The error comes from both Google and Odoo.
Google Calendar is not case sensitive: if a user creates a meeting on
Google Calendar and adds an email address with uppercases, the latter
will be converted with lowercases. (On step 3, on Google Calendar, we
can notice that PA's email address does not contain any uppercase)
On Odoo side, when syncing the event, the module checks the attendees.
To do so, it uses email addresses from Odoo (with uppercases) and Google
(without uppercases):
https://github.com/odoo/odoo/blob/12cb76bdfe7a5affb7580485473be71cfa37658a/addons/google_calendar/models/calendar.py#L105-L114
`email` comes from Google and `attendees_by_emails` from Odoo.
Therefore, it will consider the email as a new attendee and will run
`find_or_create` to get the associated partner. However, this method
uses the normalized email address to find the partner:
https://github.com/odoo/odoo/blob/12cb76bdfe7a5affb7580485473be71cfa37658a/addons/mail/models/res_partner.py#L50-L63
Thus, `find_or_create` returns PA and adds the latter to the attendees
and partners (even if PA already exists in partners and attendees).
After that, the module checks if some attendees must be removed:
https://github.com/odoo/odoo/blob/12cb76bdfe7a5affb7580485473be71cfa37658a/addons/google_calendar/models/calendar.py#L115-L120
Again, `odoo_attendee` comes from Odoo and `email` comes from Google.
Therefore, it will remove PA from attendees and partners.
This explains why:
- PA has disappeared
- No partner has been created for the email address without uppercase
This fix suggests to normalize the Odoo email addresses each they are
compared with the Google ones.
OPW-2464863
closesodoo/odoo#67950
X-original-commit: 01648d37b9d5ad858d3b60dacfb724a18045f007
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
link tracker tries to get title from HTML, but the url may be not an html page
or too big html to process. It's a waste of bandwidth, but may also lead to a
Server Memory Limit error.
As a solution, make HEAD request and don't proceed to GET request if it's not an
html page or it's too big. Also, limit page downloading to 50KB.
STEPS:
- Have a standard database with link_tracker and mass_mailing.
- Create a new mass mail MM
- Add a link to a large file in MM Mail Body
- Click "SEND"
- Go to Settings / Technical / Automation / Scheduled Actions
- Open the "Process Mass Mailing Queue" or "Email Marketing: Process queue"
- Click "RUN MANUALLY"
---
opw-2457640
closesodoo/odoo#67948
X-original-commit: bdec63cf97e6904604e9f1e0bf3b6f453b6add60
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.com>
Enable Notas de Venta Documents, prepare prefix and set type so they can
be used.
Also update csv escape characters for COMPROBANTES COMPRA/CONSIGNACION in
order to proper display the csv en editors and githib.
closesodoo/odoo#67934
X-original-commit: fb62b5e3d99880bce97e1bba0a92dfd5757dab91
Signed-off-by: Josse Colpaert <jco@openerp.com>
If some RR is archived and where the a forecasted demand on the
warehouse location, it Replenishement will crash will due to the
SQL constraint. It happens because the archived RR aren't take in
account in `_get_orderpoint_action` and the method will try to
create a orderpoint with same product + location which
lead to trigger the SQL constraint `product_location_check`.
Also avoid filtered in for loop to improve performance and use the
read_group instead.
task-2439019
closesodoo/odoo#67936
X-original-commit: 6737feef848dc47120cf3d2cca84e033e869c985
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
The`picking_type_id` of the stock.rule wasn't take in account in
the search of BoM because the `_get_matching_bom` with a empty `self`.
fix it by call on the current rule.
X-original-commit: d43e9cb9ad8d1c0c020209de0e8f6ffdcbc960a1
Before this commit, when ribbon was at the right corner of a product
card, this ribbon hid the buttons in list view.
After this commit, in list view, we place the ribbon on the left to
avoid this bug. There was no better solution to fix this in stable.
task-2466120
closesodoo/odoo#67898
X-original-commit: dcddf2125652b03bf4bff385c074fef0b2096f1d
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Reduce eye catchiness of warning message when warning the user that
his changes on email and phone will also update customer.
Before, used a ribbon (ribbon_message). It is removed from crm lead model
and also of crm lead form view.
Now, only displays an orange alert sign at the end of the fields when a change
would update the customer profile. Hovering on the alert sign displays
the appropriate message. The warning icon is added on crm lead view for
both lead and opportunity types.
Python compute method of ribbon field is split in two compute methods,
one per boolean field partner_email/phone_update.
Also updates ribbon_message tests accordingly.
TaskId 2456105
COM PR odoo/odoo#66909
UPG PR odoo/upgrade#2258
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit renames the field is_website into is_auto_campaign
for clarity purpose.
The is_website field always meant that the campaigns were created automatically
in some instances. Could be created automatically via a link to the website
or even by simply creating a marketing campaign in marketing_automation.
is_auto_campaign is a better name as it does not wrongly imply that only
the website can generate campaigns automatically, while also pointing
out the automatic generation mechanism.
The utm campaigns behaviour rests unchanged.
LINKS:
TaskID: 2414694
PR: #65824
Enterprise PR: #16238
Related: odoo/upgrade#2146
Related: odoo/enterprise#16238
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The goal of this commit is to add m2m between product and blog posts
to display a list of product promoted by one blog.
And in the future the list of blog that speak about a product on
ecommerce.
task-2267830
Co-authored by jke@openerp.comclosesodoo/odoo#67920
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Before this commit, clicking on the "add a line" button on a
many2many list field directly opened the dialog without
switching the form into edit mode.
This is incorrect, the form needs to switch into edit mode otherwise
the selected records are saved and cannot be discarded.
closesodoo/odoo#67919
X-original-commit: 3608e724c6099f0eff5f14cbd844e0d7507d0d1d
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Since the quick edit behaviour has added, embedded lists
can be edited and display the "add a line" buttons in a
readonly form but not display the remove buttons
This commit fixes that inconsistency.
X-original-commit: 7cc17a345bc9cbe165d061300d91d1ac0e583fc1
The replenishement creation currently calculates the quantity to order
using a default multiple quantity of 1. In case of manufacturing route,
we want to calculate the multiple quantity according to the quantity
produced in the BoMs.
closesodoo/odoo#62766
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Before this commit, the first step of the tour pos_basic_order
waited for something not precise enough, and that was true
before anything was loaded
After this commit, we wait both the the webClient and the Chrome to be loaded
with a more specific selector
Runbot issue fingerprint: bd10372b7db10c743f38312470ff528a74bfe9dcc0348a3e1f0bd47f55764378
Runbot issue id: 1357
closesodoo/odoo#67904
X-original-commit: 166e30b132fb659aa5a35a03cc73e5225575af2b
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Translation overwriting was not working when forced by command line
arg --i18n-overwrite
This is due to the change of signature of the method, no longer
relying on the context
Fixesodoo/odoo#67419closesodoo/odoo#67873
X-original-commit: 44624f5d51a266c4fc37644d3fc36b810e722ee4
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
The crash manager doesn't recognize ImbalanceJournalEntryError as
a user error and when creating a journal entry that is not balanced,
a traceback is shown instead of the normal UserError dialog.
In this commit, we fix this issue by getting rid of the new error
and put back the use of UserError when checking the balance of an
account move. We also make sure that the feature in pos where we
show a wizard to unblock the user from closing session with
imbalance amount is intact.
closesodoo/odoo#67743
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
The popup to apply the discount of the first SO line to the other lines didn't appear
when the first line was a section or a note.
closesodoo/odoo#67907
X-original-commit: 995ba0c2033455a2092439e9728b3f731381c742
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The 'addMockEnvironment' test utils allows to patch a lot of stuff,
including the session, for the sake of a test. However, it assumes
that it is only called once inside a test (or at least, that its
cleanUp function is always called before it is called again).
In this hr_attendance test, it isn't the case. 2 client actions are
instantiated, and addMockEnvironment is called for each of them,
in particular to patch the session.
The first call stores the current session (the real one), to restore
it in its cleanup (1). The second call stores the current session
(the mocked one, produced by the first call), to restore it in its
cleanup (2). The cleanup functions are called in order, so (1)
before (2), meaning that at the end, we end up with the session
being the mocked one of the first call to addMockEnvironment.
The very short term solution is to ensure, in this test, that the
cleanup functions are called in the correct order. For the long
term, we are working on a robust mechanism to correctly clean up
everything after a test.
Issue spotted in the assets revamp task, which mixed a bit the
order of the tests.
closesodoo/odoo#67891
X-original-commit: bb43c74dd10c76b8a80d5749106b86432b13909e
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Without this commit, all tests executed after that one would use
the patched version of the FormViewDialog.
Issue spotted in the assets revamp branch, by moving form_tests.js
after calendar_tests.js
closesodoo/odoo#67887
X-original-commit: ff19ee8d8b39a719a09dd9f6060faa3afa474da3
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
The tour system is based on many assumptions, some of those not being
true all the time. In practice, it works most of the time, but when
some slight changes occurs, we may observe undeterministic behavior.
This was actually the case in a dev branch working on assets: the order
of some files was changed, and it caused crashes in various tours.
This helped us identify two issues in the Tip class:
- the Tip class may be destroyed before it is completely started (so,
the destroy method should not assume that the code in start was called
- the attach_to method should not resolve if the tip was destroyed
meanwhile. This is critical, because some code uses that promise to act
on the widget.
This commit fixes both of these issues.
closesodoo/odoo#67896
X-original-commit: b88b634a0363a55411290e54e37806cfec1b2de5
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
The code added in [1] to update style for multi image selection
is not compatible with .fa icons and causes a strange behaviour when
trying to select one.
The goal of this commit is to fix style for selected icons on media
dialog.
Also fixes the fact the icons were not centered before.
[1]: https://github.com/odoo/odoo/commit/bb65b742e7eec000248b7df0f048dda61ac3ff5aclosesodoo/odoo#67846
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
Currently, In channels listing, the order of the channels is case sensitive.
The Uppercase names are listing first and then all the Lowercase ones.
but it should be displayed in the alphabetical case insensitive order.
With this commit, we have resolved this issue and now channels are listing
in case insensitive alphabetical manner.
Task : 2453592
closesodoo/odoo#67889
X-original-commit: 4445207161c84d2854055df63013c1361e5d4697
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this commit:
When deleting/archiving any user, the user’s related chat changed name due to
losing one of its members.
After this commit:
Chat name should remain the same after archiving/deleting the user.
Reasoning:
The unsubscribe was meant to target channels of type channel specifically.
`test_channel_auto_unsubscribe_archived_or_deleted_users` has been reintroduced
after having been removed by mistake in eda542c82f84d7b5589846691b9cb6b7f1021947
task-2442235
closesodoo/odoo#67884
X-original-commit: cb4bd4cbc4a36276cc6c9cb68e51c260e7c0d761
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Since e86f892a7b
We have the possibility to display a "lost" and a "won" ribbon on the crm.lead
kanban view.
In this commit, we change things around a bit:
- The "WON" ribbon was removed.
Since it was redundant with the stage anyway and not very useful.
- The "LOST" ribbon is now always displayed in the kanban view.
And not only when coming from "duplicate leads".
In addition, leads displayed when coming from the stat button on the
res.partner form view now also shows lost leads (active_test=False).
This can be helpful for the end user because he wants to know "all the deals
that are in progress/lost/won with this specific contact".
Task-2349526
closesodoo/odoo#67693
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Until now, if you have 2 tags (t1, t2) on blog post (P) of blog (B),
we ask to index:
/blog/B/post/P
/blog/B/post/P/t1
/blog/B/post/P/t2
Now, we only ask to index:
/blog/B/post/P
opw-2413811
closesodoo/odoo#67845
X-original-commit: bd8268a36cbe098935555edee8c16b7667c912fc
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Issue:
If we get a 'false' for the real_owner_id from the extendedProperties, we will get an error
ValueError: invalid literal for int() with base 10: 'false'
Fix:
We make sure to set a user for the real_owner_id var if it return a 'false' before
closesodoo/odoo#67840
X-original-commit: 735614a127499843bc7bd701794870234e743a88
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Nicolás Mac Rouillon