Followup of odoo/odoo#95623 (introduce scheduled message notification) as well
as odoo/odoo#99482 (support scheduled datetime from template to composer in
both comment and mailing modes).
Task-3093257 (Mail: The Composer Update)
Part-of: odoo/odoo#107356
It is still using some outdated classes for margin. Layout was a bit
broken, especially the "Preview as PDF" helper-like line.
Task-3093257 (Mail: The Composer Update)
Task-3149286 (Account: Cleanup account.invoice.send wizard)
Part-of: odoo/odoo#107356
Due to new composer, it is a bit less necessary to create them on the fly
randomly. Some quick code cleaning is performed to better understand code
and variables. Notably 'default_get' override was a bit messy and should
not return unwanted values.
Task-3093257 (Mail: The Composer Update)
Task-3149286 (Account: Cleanup account.invoice.send wizard)
Part-of: odoo/odoo#107356
'applicant_id' name is misleading as one could think it is a m2o. Better
name it 'applicant_ids' to better highlight it is a o2m. Moreover it
avoid conflicts with default value 'default_applicant_id' propagated from
some views (notably jobs kanban view).
Task-3093257 (Mail: The Composer Update)
Part-of: odoo/odoo#107356
Update query counters now that fields are editable computed fields. Some
counters are higher as the usage of composer in code is now closer to the
usage in view, with fields being correctly computed. Some other counters
are a bit lessened, but it globally stays the same.
Task-2088884 (Mail: Use editable computed stored fields in composer)
Part-of: odoo/odoo#107356
PURPOSE
Purpose of this task is to remove the _onchange_template_id method on composer
model. Split it into editable computed stored fields. It gives a better control
of value generation and avoid having to call the onchange when composer is
invoked in code.
SPECIFICATIONS
Remove onchange as it is not used anymore. All fields have been converted.
Task-2088884 (Mail: Use editable computed stored fields in composer)
Part-of: odoo/odoo#107356
RATIONALE
Remove _onchange_template_id / defaults usage for composer fields. It
lacks control and make value computation hard to understand and predict.
PURPOSE
Split _onchange_template_id + default_get + get_record_data usage into editable
computed stored fields. Each field should have its own method with its triggers
(template, composition mode, ...).
SPECIFICATIONS
Improve composer to correctly compute field ``subtype_id`` in compute method.
It is currently always set to be a 'comment' subtype. However in mass mailing
mode it is not used, as we do not use the value. Better void it directly.
Task-2088884 (Mail: Use editable computed stored fields in composer)
Part-of: odoo/odoo#107356
RATIONALE
Remove _onchange_template_id / defaults usage for composer fields. It
lacks control and make value computation hard to understand and predict.
PURPOSE
Split _onchange_template_id + default_get + get_record_data usage into editable
computed stored fields. Each field should have its own method with its triggers
(template, composition mode, ...).
SPECIFICATIONS
Improve composer to correctly compute field ``force_send`` in compute method.
It is currently computed in a default_get override.
It is set to True in mass mailing mode (send directly by default) and in
monorecord comment mode (send notifications right now). Batch comment delays
notification to use the email queue.
Task-2088884 (Mail: Use editable computed stored fields in composer)
Part-of: odoo/odoo#107356
RATIONALE
Remove _onchange_template_id / defaults usage for composer fields. It
lacks control and make value computation hard to understand and predict.
PURPOSE
Split _onchange_template_id + default_get + get_record_data usage into editable
computed stored fields. Each field should have its own method with its triggers
(template, composition mode, ...).
SPECIFICATIONS
Improve composer to correctly compute fields ``attachment_ids`` and reports
(``report_template_ids`` on template that generates reports) in compute method.
Computation is based on template and composition mode. In monorecord comment
mode, template is used to generate attachments based on both attachment_ids
of template, and reports coming from report_template_ids. Those are generated
based on the current record to display. As template generation returns a list
of tuples, new attachments are created on the fly during the compute.
In batch or email mode, only attachment_ids from template are used on the
composer. Reports will be generated at sending time.
When template is removed, attachments are reset.
Task-2088884 (Mail: Use editable computed stored fields in composer)
Part-of: odoo/odoo#107356
RATIONALE
Remove _onchange_template_id / defaults usage for composer fields. It
lacks control and make value computation hard to understand and predict.
PURPOSE
Split _onchange_template_id + default_get + get_record_data usage into editable
computed stored fields. Each field should have its own method with its triggers
(template, composition mode, ...).
SPECIFICATIONS
Improve composer to correctly compute fields ``partner_ids`` in compute
method.
Computation is coming either from template, either from context. When having
a template it uses its 3 fields 'email_cc', 'email_to' and 'partner_to' in
monorecord comment mode. Emails are converted into partners, creating new
ones when the email does not match any existing partner. Composer does not
deal with emails but only with partners.
When having a template in other modes, no recipients are computed as it is
done at sending time. When removing the template, reset it.
When not having a template, recipients may come from the parent in comment
mode, to be sure to notify the same people.
Task-2088884 (Mail: Use editable computed stored fields in composer)
Part-of: odoo/odoo#107356
RATIONALE
Remove _onchange_template_id / defaults usage for composer fields. It
lacks control and make value computation hard to understand and predict.
PURPOSE
Split _onchange_template_id + default_get + get_record_data usage into editable
computed stored fields. Each field should have its own method with its triggers
(template, composition mode, ...).
SPECIFICATIONS
Improve composer to correctly compute fields ``scheduled_date`` in compute
method.
Scheduled_date computation is coming either from template, either reset. When
having a template with a value set, copy it (in batch mode) or render it (in
monorecord comment mode) on the composer. When removing the template, reset it.
Task-2088884 (Mail: Use editable computed stored fields in composer)
Part-of: odoo/odoo#107356
RATIONALE
Remove _onchange_template_id / defaults usage for composer fields. It
lacks control and make value computation hard to understand and predict.
PURPOSE
Split _onchange_template_id + default_get + get_record_data usage into editable
computed stored fields. Each field should have its own method with its triggers
(template, composition mode, ...).
SPECIFICATIONS
Improve composer to correctly compute fields ``model`` and ``res_ids`` in
compute methods.
Model can be set from parent or using 'active_model' context key frequently
used as the composer is most invoked from list or form views.
Res Ids computation may come from parent in comment mode, if set. It takes
the parent message's res_id. Otherwise the composer uses the 'active_ids'
context key, unless it is too big to be stored in database. Indeed when
invoked for big mailings, 'active_ids' may be a very big list. Support of
'active_ids' when sending is granted in order to not always rely on 'res_ids'
field. When 'active_ids' is not present, fallback on 'active_id'.
Task-2088884 (Mail: Use editable computed stored fields in composer)
Part-of: odoo/odoo#107356
RATIONALE
Remove _onchange_template_id / defaults usage for composer fields. It
lacks control and make value computation hard to understand and predict.
PURPOSE
Split _onchange_template_id + default_get + get_record_data usage into editable
computed stored fields. Each field should have its own method with its triggers
(template, composition mode, ...).
SPECIFICATIONS
Improve composer to correctly compute field ``mail_server_id`` in compute
method. Copy value from template when updating it, if set on template. When
removing the template, reset it.
Task-2088884 (Mail: Use editable computed stored fields in composer)
Part-of: odoo/odoo#107356
RATIONALE
Remove _onchange_template_id / defaults usage for composer fields. It
lacks control and make value computation hard to understand and predict.
PURPOSE
Split _onchange_template_id + default_get + get_record_data usage into editable
computed stored fields. Each field should have its own method with its triggers
(template, composition mode, ...).
SPECIFICATIONS
Improve composer to correctly compute fields ``body`` and ``subject`` in
compute methods.
Subject computation is coming either form template, either from context.
When having a template with a value set, copy it (in batch mode) or render
it (in monorecord comment mode) on the composer. Otherwise it comes from
the parent (if set), or computed based on the generic '_message_compute_
subject' method in monorecord comment mode, or set to False. When removing
the template, reset it.
Body computation is coming either from template, either reset. When having
a template with a value set, copy it (in batch mode) or render it (in
monorecord comment mode) on the composer. When removing the template, reset it.
Task-2088884 (Mail: Use editable computed stored fields in composer)
Part-of: odoo/odoo#107356
RATIONALE
Remove _onchange_template_id / defaults usage for composer fields. It
lacks control and make value computation hard to understand and predict.
PURPOSE
Split _onchange_template_id + default_get + get_record_data usage into editable
computed stored fields. Each field should have its own method with its triggers
(template, composition mode, ...).
SPECIFICATIONSS
Improve composer to correctly compute fields ``reply_to(_force_new)`` in
compute methods.
Reply_to computation is coming either from template, either reset. When having
a template with a value set, copy it (in batch mode) or render it (in
monorecord comment mode) on the composer. When removing the template reset it.
Reply_to_force_new computation depends on model. If it does not inherit from
MailThread, avoid replies to be considered as thread updates, they will instead
follow the routing rules (alias, ...).
Task-2088884 (Mail: Use editable computed stored fields in composer)
Part-of: odoo/odoo#107356
RATIONALE
Remove _onchange_template_id / defaults usage for composer fields. It
lacks control and make value computation hard to understand and predict.
PURPOSE
Split _onchange_template_id + default_get + get_record_data usage into editable
computed stored fields. Each field should have its own method with its triggers
(template, composition mode, ...).
SPECIFICATIONS
Improve composer to correctly compute fields ``email_from`` and ``author_id``
in compute methods.
Email_from computation is coming either from template, either from context.
When having a template with a value set, copy it (in batch mode) or render it
(in monorecord comment mode) on the composer. Otherwise try to take current
user's email. When removing the template, fallback on default thread behavior
(which is current user's email).
Author computation is not controllable from the template currently. We therefore
try to synchronize it with the given email_from (in rendered mode to avoid
trying to find partner based on qweb expressions), or fallback on current user.
Task-2088884 (Mail: Use editable computed stored fields in composer)
Part-of: odoo/odoo#107356
RATIONALE
Remove _onchange_template_id / defaults usage for composer fields. It
lacks control and make value computation hard to understand and predict.
PURPOSE
Split _onchange_template_id + default_get + get_record_data usage into editable
computed stored fields. Each field should have its own method with its triggers
(template, composition mode, ...).
SPECIFICATIONS
Improve composer to correctly compute field ``auto_delete(_keep_log)`` in
compute methods.
For auto_delete, computation is coming either from template, either from
composition mode. When having a template, its value copied. Without template
it is True in comment mode to remove notification emails by default. In email
mode we keep emails (backward compatibility mode).
For auto_delete_keep_log, it is used only in email mode. It is used to keep
the core message when unlinking sent emails. It allows to keep the message as
a trace in the record's chatter. In other modes it has no use and can be set
to False. When auto_delete is turned off it has no usage.
Task-2088884 (Mail: Use editable computed stored fields in composer)
Part-of: odoo/odoo#107356
RATIONALE
Remove _onchange_template_id / defaults usage for composer fields. It
lacks control and make value computation hard to understand and predict.
PURPOSE
Split _onchange_template_id + default_get + get_record_data usage into editable
computed stored fields. Each field should have its own method with its triggers
(template, composition mode, ...).
SPECIFICATIONS
Improve composer to correctly compute field ``record_name`` in compute method.
Computation is coming either from parent message, either from the record's
display name in monorecord comment mode. In batch mode it makes no sense to
compute a single record name. In email mode it is not used anyway.
Computing it in composer allows to benefit from its computation to give it to
the message created afterwards during message_post.
Task-2088884 (Mail: Use editable computed stored fields in composer)
Part-of: odoo/odoo#107356
When using the mail composer in comment mode on models that do not inherit
from mail.thread, the post is transformed into notification process. Instead
of calling 'message_post' on the records (which would crash) 'message_notify'
is called, using MailThread as abstract class (which creates notifications
without having to inherit from mail.thread).
However some parameters from the composer are not supported when calling
'message_notify'. This commit fixes it and adds tests accordingly.
Followup of odoo/odoo#99482
Task-2710804 (Mail: Clean MailThread API)
Part-of: odoo/odoo#107356
This field will be used to remove low-level asserts using existence of
'message_post' on a given model instead of correctly checking the
inheritance on mail.thread.
This is going to increase a bit query counters but those queries should
be fast and have no real impact on performances.
Task-2088884 (Mail: Use editable computed stored fields in composer)
Part-of: odoo/odoo#107356
In some cases, a given user may create a message in behalf of other people.
This happens for example
* when calling message_notify to send notifications in a given flow, while
setting author_id to someone else (e.g. appointment flow who send invite
as notification, using the event responsible as author);
* when using templates with email_from set which may update the author_id
to match the email_from;
Notably with message_notify the current user may create a message he cannot
read afterwards, as he is not the author (as in 'author_id' field value)
and cannot read the message even with access on related record (as it is
a 'user_notification').
In this commit we relax a bit the 'read' rule on mail.message to allow reading
a message the user created.
Task-3093257 (Mail: The Composer Update)
Part-of: odoo/odoo#107356
When posting a message, author is added in followers in order to receive
answers. They also do not receive its own messages, to avoid being notified
of something they just posted.
However the real author is not always the message author. In this commit
we better define this author
* when current user is active, real author is the current user. It means
posting on behalf of someone will send answers to you, not to the
spoofed partner;
* when current user is inactive, real author is the message author. An
inactive current user means the post was probably done as sudo, aka
in the mailgateway or frontend. In that case we don't want to add
odoobot in followers, but the actual message author;
Task-3093257 (Mail: The Composer Update)
Part-of: odoo/odoo#107356
Currently notification process called notably by message_{post,notify} does
not notify message's author by default. Rationale is that as he typed the
message he is already aware of it.
However in some cases we want to skip this step, notably when messages are
generated in the name of the author and when we want him to be notified if
he should.
This is currently controllable through a context key 'mail_notify_author'.
In this commit we add an explicit parameter propagated through the notify
process, allowing to remove some context key usage and instead use real
parameters.
Note that all context keys usage cannot be removed as it is not always
possible to propagate this parameter.
Followup of odoo#99482
Task-2710804 (Mail: Clean MailThread API)
Part-of: odoo/odoo#107356
Method 'message_notify' is a simplified version of 'message_post' to use
to notify people of something, without posting on a document. It creates
a "user notification", a specific kind of message.
In this commit we make 'message_notify' process attachments like posting
does. That way the API is more similar between those two methods. Moreover
it allows to give 'attachments' to notify. Those are then transformed into
real 'attachment_ids' and converted if they come from the composer.
That way the mail composer can be used in notification mode with attachments.
This happens notably when using a template on a record that does not inherit
from MailThread. It is a classic usage of 'message_notify' which allows
notifying on documents that have no chatter, notably technical or admin
oriented models.
Followup of odoo/odoo#99482
Task-2710804 (Mail: Clean MailThread API)
Part-of: odoo/odoo#107356
Replace them by admin, which should globally be the same as employee. Testing
with system is a remaining of old times, when bichons were running freely in
the court.
Task-3093257 (Mail: The Composer Update)
Part-of: odoo/odoo#107356
As this matter is a bit complicated due to synchronization / desynchronization
of author and email, some asserts are added to help understanding the changes.
To ease converting field into an editable stored field, some additional
checks are added in tests to ease debugging and avoid regressions.
Task-2088884 (Mail: Use editable computed stored fields in composer)
Part-of: odoo/odoo#107356
Purpose of this commit is to add some tests about 'res_domain' usage in
the composer. As it takes over 'res_ids' when being set, being sure all
use cases are covered is better, especially in batch comment mode that
has been recently added.
Followup of odoo/odoo#99482
Task-3035101 (Mail: Support batch-posting from composer)
Part-of: odoo/odoo#107356
Sometimes due to new ids / not existing records for previewing crash may
happen when rendering the preview of templates. In this commit we rewrite
a bit the computation to try to be more resistant.
Task-3093257 (Mail: The Composer Update)
Part-of: odoo/odoo#107356
Using 'res_domain' should always activate the batch mode, either in mailing
or comment mode. In this commit we fix some glitches linked to the usage
of this new mode recently introduced.
Followup of odoo/odoo#99482
Task-3035101 (Mail: Support batch-posting from composer)
Part-of: odoo/odoo#107356
As subtype has no usage in mail mode, let us consider subtype_is_log as being
True in mail mode, as it eases display of buttons. This is its main usage
aka display "Log" instead of "Send" on composer. In mail mode it should
always be send.
Followup of odoo/odoo#99482
Task-2710804 (Mail: Clean MailThread API)
Part-of: odoo/odoo#107356
Previously, reward_id was an array of two elements containing
the ID and name of the reward. But in the frontend,
reward_id is supposed to be an int with the ID
Adaptation of the _prepare_order_line function in the following modules:
- point_of_sale
- pos_restaurant
- pos_loyalty
Now the data is correctly sent to the frontend and the error
is no longer present.
closesodoo/odoo#111048
Signed-off-by: Heinz Robin (rhe) <rhe@odoo.com>
Debit Notes are a type of financial documents that is not very often used. Even though it's an official document type, in many countries their usage is not
Odoo does not come with a preinstalled Debit Note management, but it can be added by installing the module account_debit_note. The module as mostly been developped following localisation requirements, and while it's a corner case, it appears all the time in one of our most critical screen. Let's make it a bit more discrete.
task-3125955
closesodoo/odoo#109539
Signed-off-by: Laurent Smet <las@odoo.com>
All the localisation should be written in english and then translated to the native language of the country. In this case, the Dutch localisation was written is Dutch, this PR translate all the module in english and add the corresponding PO file in Dutch.
closesodoo/odoo#108954
Task-id: 3115909
Related: odoo/enterprise#35345
Signed-off-by: Laurent Smet <las@odoo.com>
Before this PR, all this localisation was written in Finnish, but all the localisation have to be written in english and then translated back in the native language. This PR correct that.
closesodoo/odoo#111107
Task-id: 3151267
Related: odoo/enterprise#36338
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
Before this PR, all this localisation was written in spanish, but all the localisation have to be written in english and then translated back in the native language. This PR correct that.
closesodoo/odoo#110930
Task-id: 3149070
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
All the localisation should be written in english and then translated to the native language of the country. In this case, the Panama localisation was written is Spanish, this PR translate the module in english and add the corresponding PO file in spanish.
closesodoo/odoo#110656
Task-id: 3127385
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
All the localisation should be written in english and then translated to the native language of the country. In this case, the Uruguayan localisation was written is Spanish, this PR translate the module in english and add the corresponding PO file in spanish.
closesodoo/odoo#109504
Task-id: 3126154
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
Steps to reproduce:
- increase price_precision in decimal accuracy (in debug mode)
- create a product with multiple digits
- create a PO with that product
- unit price is rounded to 2 digits (currency pricision)
Bug:
in previous versions conversion was only done if currency
was different
Fix:
do not round during conversion and round to the highest digits
(alternatively we could revert to only converting if currecy is
different and accept the loss of precission in that case)
the wrong currency was used also for the conversion
opw-3050044
closesodoo/odoo#111223
X-original-commit: 2e46bf073c2251ce3d3ab5d5184feceb741df6db
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
The lack of a default `options` parameter for `toggleLinkTools` led to a trace
when this method was called without parameters.
This method was introduced by [1].
This commit fixes it by adding an empty object as default parameter.
[1]: https://github.com/odoo/odoo/pull/106796/commits/862d93f9eef16ec45b0d27b246fae560f7feaf1e
task-3149496
opw-3149496
opw-3151829
closesodoo/odoo#111222
X-original-commit: 24293e2a3217d0b851a3ab1c083f2984efb31d60
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Since [1] when selecting item images, the 'Blocks' tab is displayed
while the options are refreshed. This is visible because the image
selection awaits an RPC which therefore allows the browser to render
the 'Blocks' tab selected version of the display.
This commit prevents the return to the 'Blocks' tab to be rendered by
waiting for the image info to be obtained on start.
Steps to reproduce:
- Drop an "Items" block.
- Click on an image.
- Click on another image.
=> The options panel flickers on the 'Blocks' tab before showing the
second image's options.
[1]: https://github.com/odoo/odoo/commit/0acc5e784b15d9c963660da3781763448503f33e
task-2821398
closesodoo/odoo#111094
X-original-commit: d5cb2810968476b82f30582cd0d6cfdbaf351b2b
Signed-off-by: Guillaume-gdi <gdi@odoo.com>
Co-authored-by: Benoit Socias <bso@odoo.com>
Before this commit:
Importing multiple translations was failing due to concurrent update
After this commit:
1. `translation_importer.save` is moved out of the `try except` to prevent
`UserError` overriding `OperationalError`. So the service can retry the
transaction.
2. batch import is supported to allow RPC to import multiple translations at
once, which is faster and has lower chance to trigger OperationalError
closesodoo/odoo#111211
X-original-commit: 0545f323a67a3bf42d76c94c4d4c375245a69417
Signed-off-by: Raphael Collet <rco@odoo.com>
before this commit, when try to create a sale order without inputting pricelist field it was showing exception like "The operation cannot be completed:
- Create/update: a mandatory field is not set."
after this commit, user cannot save the record without filling pricelist field
closesodoo/odoo#111209
X-original-commit: 5ff011912e7dac8177d4a03ff51534e29fa4ddb4
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Have a product P configured with:
* Product Type: Storable Product
* Product category:
* costing method: standard
* Inventory Valuation Automated
* Price Difference Account: "500000 Cost of Goods Sold"
* Cost $100
Activate Multicurrency:
* USD main currency, CZK foreign currency
* On CZK set the rates
* date1, Unit per USD: 30
* date2, Unit per USD: 25 (date2 > date1)
* date3, Unit per USD: 26 (date3 > date2)
Create a purchase order:
* Date: date2
* Currency: CZK
* Order line:
* Product P
* Quantity 10
* Unit price 3000
Confirm, receive product on date2 (svl needs to be in date2)
Create the vendor bill with:
* Bill date: date 1
* Accounting date: date 3
Confirm the bill
Issue
Check the bill journal items. Price difference account is debited with 4000 czk.
This amount is not correct.
The valuation layer price unit is 100$
At the receipt date the price unit should be 2500czk
The price unit difference 3000-2500 = 500czk
Price difference 500*10 = 5000czk
The issue occur because the price difference unit is converted at bill
accounting date, resulting in 4000czk
opw-3063809
closesodoo/odoo#111199
X-original-commit: bbc0b003f6ff08a50196e07b66083ee7e8896150
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Issue:
Merchant account created inside Philippine will use PesoPay,
created inside Thailand will use SiamPay, and created inside
Indonesia will use BimoPay. Currently. only PayDollar is
available.
Cause:
Missing PesoPay, SiamPay and BimoPay.
Solution:
Add a brand setting on payment provider to allow user to select
which branch will be used.
More:
- What is PayDollar, PesoPay, etc. to AsiaPay?
PayDollar, PesoPay, SiamPay, BimoPay is the same system under AsiaPay
but is for different countries to apply.
PesoPay is for the PH market
SiamPay is for the TH market
BimoPay is for the ID market
while PayDollar is for all other market likes HK, CN, MO, TW, SG, MY,
IN, VN, NZ and AU
- Why are there multiple endpoints for a given API?
Below reasons are from AsiaPay side
Local regulators requirements for BimoPay
Branding purposes to localize for the users for PesoPay and SiamPay.
- Why didn't we integrate all these endpoints in the first version of
our AsiaPay implementation?
We got in touch with AsiaPay after our first integration. Therefore
after partnership established with AsiaPay, they provide more
integration guides on the whole development
- If many customers ask for these endpoints?
Right now, there is no customers asking for these endpoints. However
if they register AsiaPay under certain countries, they have to use
the other endpoints otherwise they will not able to use AsiaPay on Odoo at all.
task-3073748
closesodoo/odoo#110357
Related: odoo/documentation#3423
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Steps to reproduce:
- create an employee and fill in the email address;
- duplicate this employee;
- change the email address of the new employee.
Issue:
The email address is changed on both employees.
Cause:
When we duplicate an employee, we keep the same contact.
By modifying the email address, we will modify the contact's email address.
Then we "synchronise" all employees with their contact
using the contact information.
Solution:
When an employee is duplicated, a new contact must be created.
Therefore it is necessary to avoid copying the `work_contact_id` field.
opw-3144129
closesodoo/odoo#111201
X-original-commit: 1582f6834bee2123f8703b2ae52996b0978e2311
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>
Thibault Delavallée