Currently since the input has no name we can't
retrieve the file when using FormData instance.
This commit allows the developer to pass an input
name when instanciating a FileUploader component.
Task-2855647
X-original-commit: 33bc32c52bef4787ae2e529f05837c2f7dbddc7f
Part-of: odoo/odoo#102314
The financial account must be editable until a journal items is set, which wasn't the case before this PR. I also switched the two fields so that's more logical for the user.
closesodoo/odoo#102309
Task-id: 3006879
X-original-commit: 5cc72bb6d6f9a04ec32e47d02ebfaf8e12aba559
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
There was an option in the legacy ModelFieldSelector
that could be used to prevent following the relations.
This option was lost since the widget has been
converted. This commit simply reintroduces the option.
closesodoo/odoo#102308
X-original-commit: 673faab4dec7a0df434cf0575303df97a36db0f1
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Customer display does not show the appropriate logo when multi-company is
enabled. The logo shown is always the logo of the default company.
Step to reproduce the issue:
1) Install Point of Sale and set up a second company
2) Put a logo on both companies (different ones)
3) Create a POS session on the newest company (not the default one)
4) In this session, activate Customer Display
5) Launch the session and open the Customer Display
The logo shown is the logo of the default company.
Solution: The issue is that when fetching the logo, we don't include
information about the current company. Thus, we include the logo of the default
company (at url /logo). We can easily specifiy which logo we need via the url
/logo?company={company_id}. As dynamic information cannot be included into a
CSS, we include this into the XML as it is done with other images rendered.
In our case, we don't need to retrieve the logo and map it to base 64 (for
ressources requiring to be logged in) because the logo is a resource available
to anyone.
opw-2745014
closesodoo/odoo#102257
X-original-commit: ceb244d31a72ad826e841dfd06b7e1ed59f2c994
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Desausoi Laurent (lade) <lade@odoo.com>
If the decimal separator of the currently selected language is a comma,
exporting data in an xlsx would use a wrong float format
Steps to reproduce:
1. Install Invoicing
2. Go to Settings > Languages, add 'French / Français' language and
switch to it
3. Go to Facturation > Fournisseurs > Factures
4. Export the data (there should be at least one amount with a decimal
part)
5. The decimal part of the amounts is not displayed
Solution:
Always use the same decimal separator to print in the xlsx as we can
only use a dot as a decimal separator (the comma is used as the thousand
separator). The value will then be displayed to the user according to
his OS regional settings (see https://xlsxwriter.readthedocs.io/format.html#number-formats-in-different-locales)
Problem:
When using a comma for the float format, we actually specify the format
of the integral part of the number (the thousands) without displaying
the decimal part (which is represented with the dot)
opw-2965984
closesodoo/odoo#102255
X-original-commit: 21efa4f18266a5c5c57157035c2357ed3e147a69
Signed-off-by: Julien Castiaux <juc@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
After the update of the bootstrap lib, the kanban records to be found in
the menu Project Stages of Project > Configuration (after activation of
a setting option) had each two weird borders. Here, we simplify the
kanban-box template in order to get only one border as it is in 15.0.
closesodoo/odoo#102249
X-original-commit: 839bdd0a853f88bfaeb0dd698d60e2168dc54188
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The condition that determines whether to display the tax base was wrong
It should be displayed when either condition is met:
- There are multiple tax base amounts
- The only tax base amount is not the same as the untaxed amount
Note that this last case may happen with cash discounts
closesodoo/odoo#102247
X-original-commit: a8ff4b876c8ab48177795e6ace1bb1361744c8a7
Signed-off-by: Camille Spiritus (casp) <casp@odoo.com>
Signed-off-by: Stanislas Gueniffey (stgu) <stgu@odoo.com>
Since the usage of the `CSS Grid` some view are broken due to too much
CSS rules conflicting together.
The new form view system is less tolerant to missing colspan.
This commit, change the colspan when needed (e.g. no label)
Steps to reproduce:
* Go to sale
* Select the product menu
* Select a product (e.g. Printer)
* Some fields on the form view (in panel) are not aligned => BUG
closesodoo/odoo#102246
X-original-commit: 4813d1ebd4295c8be7ee6b6a892604f15cc43fce
Related: odoo/enterprise#32320
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: Romeo Fragomeli (rfr) <rfr@odoo.com>
This commit, excludes the first separator from the selector to avoid too
top space.
Steps to reproduce:
* Go to sale
* Select the product menu
* Select a product (e.g. Printer)
* Click on the Price tab
* The separator on the right is misaligned => BUG
X-original-commit: 0e0a2014b31e2fc6423e80971ac451a2dfe89de9
Part-of: odoo/odoo#102246
This commit, excludes X2Many list from the selector to avoid to use
negative margin when we are in a group.
Steps to reproduce:
* Go to sale
* Select the product menu
* Select a product (e.g. Printer)
* Click on the Price tab
* The X2Many list is misaligned of the group => BUG
X-original-commit: d718ee455c05c0df419f66c0a884207322199282
Part-of: odoo/odoo#102246
Purpose
=======
Check the existence of the relational properties (many2one / many2many) in
batch and prefetch the values in batch as well to reduce the number of SQL
queries.
Allow to add the properties field in the kanban view. An option has been added
in the property definition, "View In Kanban", to decide which field must be
visible in the kanban view. This is useful when having several properties
and to avoid cluttering the UI.
This merge also contain some fixes, see sub commits for more details.
Task-2965523
closesodoo/odoo#102243
Forward-port-of: odoo/odoo#101417
Related: odoo/enterprise#32318
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
The debounced timeout is useful for the auto complete when it's used for
many2one and many2many because it makes RPC calls.
But for the property tags, we don't need this timeout and it will make
the component more reactive.
Task-2980121
X-original-commit: 9701738365c50e911cb704807c929fbbb4b43c43
Part-of: odoo/odoo#102243
Bug
===
In knowledge, when we move for the first time a property, the popover
position is wrong. The technical reason is that the component DOM is
updated one time before the props changed, and so the DOM is not
up to date when we compute the new position.
Also, the popover might change it's relative position (top VS bottom)
and so the small arrow might be incorrect in that case. Always remove
it (rectangle popover better than a wrong arrow direction).
Task-2980121
X-original-commit: de37a3393b31d48add36fc6be5febf70dc3db31e
Part-of: odoo/odoo#102243
Purpose
=======
The style of the standard field has been changed due to the
"edit only" form view. Adapt the properties field style to match
standard field.
Fix a bug where the autocomplete of the many2many / tags is
displayed outside of the screen.
Change the external link icon to match the new one on standard many2one.
Task-2980121
X-original-commit: 0c8e4c03529d4306be295a59d987576ff2cab490
Part-of: odoo/odoo#102243
Purpose
=======
Allow to add the properties field in the kanban view.
An option has been added in the property definition, "View In Kanban",
to decide which field must be visible in the kanban view.
We need an option because in practice we might have a lot of
properties, and it might break the view.
Task-2980121
X-original-commit: 3af5a59c23183dd43341c1952a04354acbf3a60d
Part-of: odoo/odoo#102243
Purpose
=======
Check the existence of the relational properties (many2one / many2many)
in batch and prefetch the values in batch as well to reduce the number
of SQL queries.
Technical
=========
The existence is checked in the read method of the properties field,
because we have the entire recordset. Then, the non-existing ids are
remove from the properties values and the cache is updated.
Task-2965523
X-original-commit: dba9b684d29c0041a32a5508284573851b8dd097
Part-of: odoo/odoo#102243
Before this commit, when we go to a Task. Click on the Tags field
> Search More. Group by Projects.
We get a list of projects groups. Click on them and they go from
(x) to (0) due to invalid group result from read_group without
valid domain same as search_read.
So in this commit, override the read_group method to pass the valid
domain same as search_read.
task-2959382
closesodoo/odoo#102236
X-original-commit: f9e9964c7138485ba328ce5cd4c4c8905c392adc
Signed-off-by: Xavier <xbo@odoo.com>
pivot, graph, cohort views do not care to know whether a field
is readonly or required, as you cannot edit records in these views.
Even kanban is readonly in most cases:
- you can drag and drop records from one column to another,
which is prevented if the group by field is readonly
but this shouldn't rely on the fact the field is
within the architecture, as you can group by on any fields
from the search views / control panel.
Hence, this shouldn't rely entirely on the modifiers passed on the field
nodes in the view architecture alone.
- you can create new record inside the kanban,
with a simplified form, thanks to the `quick_create`,
but this uses an independant form view, in which the readonly and
required modifiers are correctly passed.
So, `modifiers="{'readonly': true, 'required': true}"` can be dropped
for kanban views as well.
This allow to spare some KB by not setting useless modifiers in views.
e.g. CRM > My pipeline pivot
Before
```xml
<pivot string="Pipeline Analysis" sample="1">
<field name="create_date" interval="month" type="row" modifiers="{"readonly": true}"/>
<field name="stage_id" type="col" on_change="1" can_create="true" can_write="true"/>
<field name="expected_revenue" type="measure"/>
<field name="color" modifiers="{"invisible": true}"/>
<field name="automated_probability" modifiers="{"invisible": true, "readonly": true}"/>
<field name="message_bounce" modifiers="{"invisible": true}"/>
<field name="probability" on_change="1" modifiers="{"invisible": true}"/>
</pivot>
```
After
```xml
<pivot string="Pipeline Analysis" sample="1">
<field name="create_date" interval="month" type="row"/>
<field name="stage_id" type="col" on_change="1"/>
<field name="expected_revenue" type="measure"/>
<field name="color" modifiers="{"invisible": true}"/>
<field name="automated_probability" modifiers="{"invisible": true}"/>
<field name="message_bounce" modifiers="{"invisible": true}"/>
<field name="probability" on_change="1" modifiers="{"invisible": true}"/>
</pivot>
```
Regarding the change of behavior shown in `addons/web/static/tests/views/kanban_view_tests.js`.
It was introduced very recently, by myself, in
odoo/odoo#100806
I revert this possibility to set readonly="0" on a field node in a
kanban view, because:
- First, this is not used anywhere in both odoo/odoo and
odoo/enterprise.
- Second, this really makes things harder if we want to do so:
- as readonly="0" is passed, the "readonly" gets removed from the node
modifiers, as they are simplified by removing falsy value:
modifiers="{'invisible: True, 'readonly': False}" becomes modifiers="{'invisible': True}"
- as readonly in not amongst the modifiers, it fallbacks on the model
field property, in the javascript code, which is readonly: True.
- the thing to do would be to still transfer "readonly"
from the field attributes to the node modifiers.
- which either mean to consider a kanban view as editable
- this will cause issues because the validation mechanism
will suddenly check the domain attribute property
https://github.com/odoo/odoo/blob/d4a92b112d0554a2624f7768feb7d54e0484469f/odoo/addons/base/models/ir_ui_view.py#L1443
and there will be plenty of views where some field used in the
domains will be missing. Besides it is pointless to validate these
domains as they are completely unused in kanban views
- either mean to find another mechanism than "editable" to decide
wheter to transfer the modifiers "readonly"/"required" or not,
which over-complicates things.
- besides only "readonly" would need to be passed, not "required.
So, to keep the code stupid simple, I remove this possibility added only
a few days ago, which is actually not used anywhere in standard for the
moment.
closesodoo/odoo#102221
X-original-commit: 69c3d5aa25655173ed66a52570559322c650c7df
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
The rendering of the partner autocomplete widget has changed a bit since its
Owl conversion, the trigger needed to be updated to reflect that.
closesodoo/odoo#102220
X-original-commit: a8fce72e12836af95af883a08bdb74b6c0343c90
Related: odoo/enterprise#32310
Signed-off-by: Georis François (fge) <fge@odoo.com>
Signed-off-by: Louis Baudoux (lba) <lba@odoo.com>
The `field_partner_autocomplete` & `res_partner_many2one` widgets are now
converted to Owl.
It required some changes in the `Autocomplete` component as we needed to
access the ref of the `<input/>` element to pass it to the `useInputField`
of `CharField`.
The hook `useInputField` was also modified to allow passing a ref directly
as parameter instead of a ref name.
X-original-commit: 0b8c86bc5b19baccf7324fd4b18d438278816a5a
Part-of: odoo/odoo#102220
There was a small graphical bug caused by the `<ul>` element being
rendered even when no options were available.
X-original-commit: 32d87b2097e550b375bdc2098cdee6c669666a3a
Part-of: odoo/odoo#102220
This commit adds the possibility to change the product tag color on a product and also to edit those tags from a submenu of the ecommerce.
task_id=2904805
closesodoo/odoo#100717
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
The session used to call this websocket route needs to have been
initiated with a call to /websocket/peek_notifications first.
closesodoo/odoo#102009
X-original-commit: 49aa391b4ef93b2de578c73a1fe852cea32abb43
Signed-off-by: Julien Castiaux <juc@odoo.com>
This commit converts `popover_widget`, `stock_rescheduling_popover`
and `mrp_workorder_popover` to OWL
closesodoo/odoo#101987
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
How to reproduce the problem:
- Install the purchase_requistion, purchase_requistion_stock, and any Localization modules such as l10n_be or l10n_in
(apart from USD currency any localization module)
- error caught only when at the time of module installation but it must have a different currency_id apart from USD
https://watch.screencastify.com/v/1C7GQKHBASyiluGGkFfV
Cause of the problem:
static values Currency USD cause the problem.
the following module will be set the currency value
l10n_be - EUR
l10n_in - INR
l10n_br - BRL
when we installed the following modules then cls.env.user.company_id.currency_id values get changes accordingly
will lead to this error
Traceback (most recent call last):
File /home/odoo/src/odoo/addons/purchase_requisition/tests/common.py, line 70, in setUpClass
cls.env.user.company_id.currency_id = cls.env.ref(base.USD).id
File /home/odoo/src/odoo/odoo/fields.py, line 1217, in __set__
records.write({self.name: write_value})
File /home/odoo/src/odoo/addons/account/models/company.py, line 301, in write
raise UserError(_('You cannot change the currency of the company since some journal items already exist'))
odoo.exceptions.UserError: You cannot change the currency of the company since some journal items already exist
opw-2945581
closesodoo/odoo#98512
Closes: https://github.com/odoo/odoo/pull/98174
X-original-commit: 70b7c57f7ea0a619a149461e0e738ddc25b822f6
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
A user can not buy a subcontracted product and directly deliver it
(dropship) to another subcontractor. Moreover, in such situation, the
received quantity is not correctly computed.
To reproduce the issue:
(Enable debug mode)
1. In Settings, enable "Storage Locations"
2. Create three products:
- P1:
- Storable
- With a vendor V1
- P2:
- Storable
- With a vendor V2
- P3:
- Consumable
3. Edit V1:
- Customer Location: Physical Locations/Subcontracting Location
4. Create two BoMs:
- Product: P1
- Type: Subcontracting
- Subcontractors: V1
- Components: 1 x P2
- Product: P2
- Type: Subcontracting
- Subcontractors: V2
- Components: 1 x P3
5. Create a PO:
- Vendor: V2
- Deliver To: Dropship
- Drop Ship Address: V1
- Products: 1 x P2
6. Confirm the PO
Error: a Validation Error is raised at `mrp.production` creation because
of a missing field (`picking_type_id`).
In some cases, when getting the values to create the MO, the basic
`_prepare_subcontract_mo_vals` does not return any `picking_type_id`.
That's the reason why an override has been added in
`/mrp_subcontracting_dropshipping` (see [1] for more details). Thanks to
this override, if the usage of the destination location is `customer`,
we know that we are in a "dropship" situation and we manually define the
`picking_type_id`:
https://github.com/odoo/odoo/blob/d73e70f22e47e81e59aff0c9f578aff260447256/addons/mrp_subcontracting_dropshipping/models/stock_picking.py#L15-L17
However, in the above case, the subcontracted stock move starts from a
subcontracted location and also goes to a subcontracted location
(because of step 3). As a result, the if-condition is not respected and
the `picking_type_id` is not defined.
Once this issue is solved, there is a second one: suppose the PO
confirmed. The user validates the transfer. New error: the received
quantity on the PO is not updated. This is because of an incorrect
condition in `/purchase_stock._compute_qty_received`:
https://github.com/odoo/odoo/blob/d0537e32e5aa4b0fe2ad674ab3ec7c42ae1a12f9/addons/purchase_stock/models/purchase.py#L306-L315
Added by [2] and modified by [3], this condition checks that:
- the destination location usage is `internal` (correct, this is a
subcontracting location)
- the source location usage is not `supplier` (correct, this is a
subcontracting location, so it is `internal`)
- the destination location is not part of the warehouse children (here
is the issue: the SM does not have any warehouse, so it gives a false
positive)
So, because of the incorrect third condition, the condition is
respected. And because `to_refund` is `False` (which is correct), we
don't do anything. That's the reason why the received quantity is not
updated.
[1] d73e70f22e47e81e59aff0c9f578aff260447256
[2] e6a1e240f1
[3] fd22fe221026e353aac7414348b029ae7e290b2f
OPW-2922546
closesodoo/odoo#102224
X-original-commit: a51b4158b964a11fa371a9eb8c877c9ec395f412
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Two dropdown were too small, it's now corrected by adding a new group.
closesodoo/odoo#102223
Task-id: 3006637
X-original-commit: 1a56ad9895f7b5b029a27cabdffbadba60cd87ef
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Signed-off-by: Maximilien La Barre (malb) <malb@odoo.com>
This commit applies the same behavior between hovering an `o_input` and
a `note-editable` inside the form view
closesodoo/odoo#102205
X-original-commit: 43b1baf10bc004a2ac5d63990b9a65aab74cba9c
Related: odoo/enterprise#32304
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: Romain Estievenart (res) <res@odoo.com>
This commit applies the same behavior between the community and the
enterprise for the `o_field_widget o_input:hover` effect.
Before this commit the hover on community applies a border on all
quadrant, now we only see the bottom border as in Odoo Enterprise
X-original-commit: 89d67a125fd8146d979c2b12ade1f4dbe5fc2441
Part-of: odoo/odoo#102205
This commit restores the behavior we had before wowl :
- Having a min-height of 180px when the node-editable is a child
field (without a parent form group).
e.g: open the form view of a `crm.lead` inside the `crm` app.
- No min-height added when the note-editable is inside a form-group
e.g: the condition & terms inside the form view of a `sale.order`
inside the `sale` app.
X-original-commit: 294e8b8ad3efca2211cff61992b3cd07493eb1bb
Part-of: odoo/odoo#102205
Task Description
In some case, when trying to display the context menu on a
pivot cell (doesn't seem to impact PIVOT.HEADER), we get a
traceback caused by the arguments of the formula take into
account in the ´getFiltersMatchingPivot`, called by the
"isVisible" property evaluation of the "set as filter" action.
These errors only rise when using a pivot with "__count" as
measure and a positional argument.
Moreover, when trying to open the context menu with a filter
defined without any field, we get another traceback.
Reproducibility
The first issue can be reproduced with the following steps:
1. Go to the CRM app
2. Create a pivot view
3. Group the row by Country
4. "Ungroup" the columns (keep only the total)
5. Set "__count" as measure
6. Insert the pivot on a new spreadsheet
7. Edit the pivot formulas to use positional argument for country_id
8. Insert a new filter on the country field
9. Right click on a pivot cell
The second issue can be reproduced with the following steps:
1. Open a spreadsheet with a pivot
2. Add a filter related to the pivot but without any field matching
3. Right-click on a pivot cell
Fix Description
The first issue is coming from the fact we try to get the value related
to a field in the pivot formula using the 2nd and 3rd argument instead
of using the last two arguments of the formula. This is fixed by passing
to getPivotHeaderValue only the last two arguments of the pivot formula.
For the second issue, we simply check that the pivot field is defined
before looking at its name.
Related Task
task-2999181
closesodoo/odoo#102204
X-original-commit: 15e0c8aba57d4e0a8c58f288a4e96f0bc884736c
Related: odoo/enterprise#32303
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Before this commit, the field terms and conditions was weardly placed
And also reducing the size of the field quick_edit_total_amount
closesodoo/odoo#102192
Task-id: 3003938
X-original-commit: 10b842da4cc641145fa672c4837b0cde1120963c
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Signed-off-by: Maximilien La Barre (malb) <malb@odoo.com>
- Make content helper more generic for programs
- Add search fields for loyalty.card
- Fix creation emails for gift cards in pos not being sent properly
- Fix validity date check on loyalty rules being inverted.
TaskId-3002190
closesodoo/odoo#102160
X-original-commit: f893fda1a40127b7510e861c96f4d4cf9d10f79d
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
The goal of this task is to review the copywriting of the tooltips
because some of them are not correct in English and others are not
valid anymore. This is also a good opportunity to make an inventory
of the tooltips we have and to add some that could be missing.
task-2860991
closesodoo/odoo#102179
X-original-commit: 5e4cf8f9f6a4372f45aa04a5965f8073bb4ea68a
Related: odoo/enterprise#32298
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Co-authored-by: Mahendra Barad <mba@odoo.com>, Prakash Prajapati <ppr@odoo.com>
This commit solves two bugs:
1. In a grouped empty list view, if you click on a sortable column,
then a crash is displayed.
How to reproduce:
- Go to a grouped empty list view with at least one sortable column
- Click on the sortable column
Before this commit :
A crash is displayed
After this commit:
Nothing happens.
2. In a grouped view with at least one open group, columns that do not
have an aggregates value cannot be sorted.
How to reproduce:
- Go to a grouped list view with at least one open group.
- Click on a sortable column that does not have an aggregates value
Before this commit:
Nothing happens
After this commit:
The records are sorted by the clicked column.
closesodoo/odoo#102143
X-original-commit: 537bbc79fe0ce34fe8b4746bf4cc86f9ebfc8a12
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Signed-off-by: Georis François (fge) <fge@odoo.com>
Keyboard navigation was misleading, and it was adding a box around
focused which was irremovable because it was injected by the browser
closesodoo/odoo#102033
X-original-commit: 519bbe4b55c907bcd71d03e34dbc706d13a2268b
Related: odoo/enterprise#32235
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, in a list view, html fields in readonly mode were
not rendered correctly. It displayed unprocessed HTML.
For the value :
<div>Hello</div>
Before this commit, it was displaying:
<div>Hello</div>
After this commit, we display:
Hello
closesodoo/odoo#101253
X-original-commit: a6292c17b886996c82c797e562b725d63d4a5b7e
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The `<span>` was not properly closed.
closesodoo/odoo#102162
X-original-commit: cb3b87f8fe66d11e1a96066a27eb3ef979bc3e39
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Steps :
- When the user is subscribed to the `Stage changed` subtype
but not `Task in progress` and on change of stage, the users only
subscribed to stage changed will not receive stage changed notification.
Cause :
- When the stage is changed it will also change the kanban_state to
in progress and due to that, it will track the kanban_state from
_track_subtype, and the user who subscribed only stage_changed will not
get notified.
Fix :
- So in this commit, prioritize the stage_id changed notification so that
when the stage_id is changed we use that one, and the in-progress won't
be triggered, but when we change the kanban state back to progress it
will be triggered. As in progress is implicit when changing the stage_id.
task-2818058
closesodoo/odoo#102172
X-original-commit: 4d952d679629a4a225ff208a6d018e11f14bf47e
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Patrick Hoste