Odoo/addons/web/static/tests/fields/relational_fields/field_many2one_tests.js, branch 14.0 The current checkout of upstream Odoo [FIX] web: Auto close dropdown is broken 2021-02-01T10:50:51+00:00 Romain Estievenart res@odoo.com 2021-01-28T14:01:32+00:00 7cb24db622b231b89558755d9c0e7d899fc994bf Steps to reproduce: 1. Go to Project App 2. Open and edit a task 3. Click on Customer => search more 5. Click on "Filters" 6. Click on "Group by" => The "Filters" and "Group by" dropdown are open at same time => bug Since odoo/odoo@e4f87710e16357f24f388159a7b1e82eccda598a, we added a way to prevent bs and owl dropdown to be open in the same time. But when the web-editor is present, the CSS selector used to match the opened modal ("search more" in this case) conflicts with the DOM created by the web-editor (modals identified by the classes: .web-editor, .note-picture-dialog, .note-link-dialog, .note-help-dialog). To avoid this conflict, this commit uses a more restrictive CSS selector to match only the first (active) opened modal (as web-editor doesn't attach its modals at the root of the body). closes odoo/odoo#65274 Signed-off-by: Pierre Paridans <pparidans@users.noreply.github.com> 
Steps to reproduce:
1. Go to Project App
2. Open and edit a task
3. Click on Customer => search more
5. Click on "Filters"
6. Click on "Group by"
=> The "Filters" and "Group by" dropdown are open at same time => bug

Since odoo/odoo@e4f87710e16357f24f388159a7b1e82eccda598a, we added a way
to prevent bs and owl dropdown to be open in the same time.

But when the web-editor is present, the CSS selector used to match the
opened modal ("search more" in this case) conflicts with the DOM created
by the web-editor  (modals identified by the classes: .web-editor,
.note-picture-dialog, .note-link-dialog, .note-help-dialog).

To avoid this conflict, this commit uses a more restrictive CSS selector
to match only the first (active) opened modal (as web-editor doesn't
attach its modals at the root of the body).

closes odoo/odoo#65274

Signed-off-by: Pierre Paridans <pparidans@users.noreply.github.com>
[FIX] web: race condition with x2many control panel 2020-11-18T08:39:40+00:00 Aaron Bohy aab@odoo.com 2020-11-10T14:52:14+00:00 e8e64f75606f1501a8be7b0bb418a296cfd8be61 The ControlPanel has been converted in Owl [1], and the code using it has been adapted accordingly. However, in the FieldX2Many, we didn't properly wait for the ControlPanel to be updated (an update of the ControlPanel was synchronous before owl, and is now async, like every Owl renderings, as it waits for the nextAnimationFrame). As a consequence, we might have tricky issues because the mounted hook of the control panel might be called multiple times for a single call to willUnmount later on. In mobile, we bind a global event handler (on scroll) in mounted, and unbind it in willUnmount, so we had leftover event handlers, that crashed when called after the ControlPanel was destroyed. Note that even if the issue popped in mobile, calling mounted on already mounted Components isn't a good idea, and this should be fixed anyway. The issue could be reproduced for instance in FieldService (with collaborative pads activated in Project), in mobile, by opening a task in Edit mode. Then, you might get a traceback by scrolling after having discarded the edition Here is a description of what technically happened: - when clicking on Edit, all widgets (including the FieldX2Many are destroyed and re-instantiated in 'edit' mode). - the pad widget directly triggers a field_changed event which causes a reset of the FieldX2Many (i.e. 'render' is called again) - the FieldX2Many detects that it already has a renderer (and a ControlPanel) so it updates them - it first updates the renderer, and when it's done, it updates the ControlPanel BUT doesn't wait for its promise, so the promise returned by that call to 'render' in FieldX2Many is resolved before the ControlPanel is actually updated - note that at this point, all thoses new widgets are not in the DOM yet - when all widgets are ready, the renderer patches the view (i.e. the former content is removed from the DOM, and the new one is attached into the DOM). As soon as this is done, the renderer calls 'on_attach_callback' on its children, including the FieldX2Many, which leads to a call to 'mounted' on the CP. - then, just before the nextAnimationFrame, Owl complete the rendering of the CP, and detects that it is now in the DOM (it wasn't at the beginning), so 'mounted' is called a second time, will cause the issue described above. This commit fixes the issue by properly waiting for the CP to be rendered in the FieldX2Many. However, this required on cascade changes: - Form view renderings with a FieldX2Many are now *really* async (+- 16ms), meaning that the user can easily trigger concurrent renderings by, e.g. clicking quickly several times on 'Edit', 'Save' or 'Discard'. Concurrent renderings are properly handled so to prevent this from happening, we disable the buttons and re-enable them when the rendering is done (like already done in [2]) - in the FieldX2Many, '_updateControlPanel' was called at several placed, but we never waited for it. As this method was originally sync, its calls have probably been naively adapted, whereas their should have been deeply rethought (for instance, as it is async, and we need to wait for it, we don't want it to be called multiple times sequentially when something happens). This commit does that work, i.e. we clean the places where this function is called such that it is (hopefully) never called sequentially twice. To do so, we changed a bit the spec of the pager in multi page, and we also fixed a paging-related bug. In a few words, here is what we did/do when adding a new row in the bottom of a full page: - before: tweak the count in the data to fool the pager and make it think that no new record has been added (so basically, let it display something wrong) - now: temporarily increase the pager limit so that the new record is displayed on the current pager, and the pager values are correct w.r.t. the displayed records. Some tests needed to be adapted accordingly. - By waiting for the ControlPanel when updating the FieldX2Many, a bunch of QUnit tests failed. Those tests have something in common: they spawn an X2Many (list or kanban theoretically, but always list in practice) containing a FieldBoolean (only field widget of /web converted in owl). When the FieldX2Many is updated, we update the renderer (i.e. re-renderer the FieldBoolean, so we have to wait for the nextAnimationFrame), and when this is done, we update the page (again, we have to wait for the nextAnimationFrame). So basically, we have to wait for two nextAnimationFrames to see the result in the DOM. For this, we added a new test util which basically does a nextTick ('owlCompatibilityNextTick'), and called it everywhere it was necessary. When everything will be written in Owl, we could get rid of this util and its calls. [1] https://github.com/odoo/odoo/commit/fbf347498f1cc7b74ef373179b7bcae201715c24 [2] https://github.com/odoo/odoo/commit/39f08950d6e20460e3a20a5b9c33e4ddf66dce78 closes odoo/odoo#61593 Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com> 
The ControlPanel has been converted in Owl [1], and the code using
it has been adapted accordingly. However, in the FieldX2Many, we
didn't properly wait for the ControlPanel to be updated (an update
of the ControlPanel was synchronous before owl, and is now async,
like every Owl renderings, as it waits for the nextAnimationFrame).

As a consequence, we might have tricky issues because the mounted
hook of the control panel might be called multiple times for a
single call to willUnmount later on. In mobile, we bind a global
event handler (on scroll) in mounted, and unbind it in willUnmount,
so we had leftover event handlers, that crashed when called after
the ControlPanel was destroyed. Note that even if the issue popped
in mobile, calling mounted on already mounted Components isn't a
good idea, and this should be fixed anyway.

The issue could be reproduced for instance in FieldService (with
collaborative pads activated in Project), in mobile, by opening
a task in Edit mode. Then, you might get a traceback by scrolling
after having discarded the edition

Here is a description of what technically happened:
 - when clicking on Edit, all widgets (including the FieldX2Many
   are destroyed and re-instantiated in 'edit' mode).
 - the pad widget directly triggers a field_changed event which
   causes a reset of the FieldX2Many (i.e. 'render' is called
   again)
 - the FieldX2Many detects that it already has a renderer (and a
   ControlPanel) so it updates them
 - it first updates the renderer, and when it's done, it updates
   the ControlPanel BUT doesn't wait for its promise, so the
   promise returned by that call to 'render' in FieldX2Many is
   resolved before the ControlPanel is actually updated
 - note that at this point, all thoses new widgets are not in the
   DOM yet
 - when all widgets are ready, the renderer patches the view (i.e.
   the former content is removed from the DOM, and the new one is
   attached into the DOM). As soon as this is done, the renderer
   calls 'on_attach_callback' on its children, including the
   FieldX2Many, which leads to a call to 'mounted' on the CP.
 - then, just before the nextAnimationFrame, Owl complete the
   rendering of the CP, and detects that it is now in the DOM (it
   wasn't at the beginning), so 'mounted' is called a second time,
   will cause the issue described above.

This commit fixes the issue by properly waiting for the CP to be
rendered in the FieldX2Many. However, this required on cascade
changes:
 - Form view renderings with a FieldX2Many are now *really* async
   (+- 16ms), meaning that the user can easily trigger concurrent
   renderings by, e.g. clicking quickly several times on 'Edit',
   'Save' or 'Discard'. Concurrent renderings are properly handled
   so to prevent this from happening, we disable the buttons and
   re-enable them when the rendering is done (like already done in
   [2])
 - in the FieldX2Many, '_updateControlPanel' was called at several
   placed, but we never waited for it. As this method was
   originally sync, its calls have probably been naively adapted,
   whereas their should have been deeply rethought (for instance,
   as it is async, and we need to wait for it, we don't want it
   to be called multiple times sequentially when something happens).
   This commit does that work, i.e. we clean the places where this
   function is called such that it is (hopefully) never called
   sequentially twice. To do so, we changed a bit the spec of the
   pager in multi page, and we also fixed a paging-related  bug.
   In a few words, here is what we did/do when adding a new row
   in the bottom of a full page:
     - before: tweak the count in the data to fool the pager and
       make it think that no new record has been added (so
       basically, let it display something wrong)
     - now: temporarily increase the pager limit so that the new
       record is displayed on the current pager, and the pager
       values are correct w.r.t. the displayed records.
    Some tests needed to be adapted accordingly.
 - By waiting for the ControlPanel when updating the FieldX2Many,
   a bunch of QUnit tests failed. Those tests have something in
   common: they spawn an X2Many (list or kanban theoretically,
   but always list in practice) containing a FieldBoolean (only
   field widget of /web converted in owl). When the FieldX2Many
   is updated, we update the renderer (i.e. re-renderer the
   FieldBoolean, so we have to wait for the nextAnimationFrame),
   and when this is done, we update the page (again, we have
   to wait for the nextAnimationFrame). So basically, we have
   to wait for two nextAnimationFrames to see the result in the
   DOM. For this, we added a new test util which basically does
   a nextTick ('owlCompatibilityNextTick'), and called it
   everywhere it was necessary. When everything will be written
   in Owl, we could get rid of this util and its calls.

[1] https://github.com/odoo/odoo/commit/fbf347498f1cc7b74ef373179b7bcae201715c24
[2] https://github.com/odoo/odoo/commit/39f08950d6e20460e3a20a5b9c33e4ddf66dce78

closes odoo/odoo#61593

Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
[REF] web: BasicModel: combine default_get and onchange 2020-08-20T13:39:25+00:00 Lucas Perais (lpe) lpe@odoo.com 2020-08-07T08:48:55+00:00 38b7462dcf7541bbcb51ac75cc1f7b6715f13ace This commit adapts the BasicModel to combine calls to `default_get` and (first) `onchange`. When creating a new record, we now only call `onchange`, which thus return default values and potential onchange values. Tests (and the MockServer) have been adapted accordingly. NOTE 1. If the `default_get` within the `onchange` returns a value for a field that is not in the view, we ignore it, and it won't be saved. Before, that value was kept and sent upon save. This change in behavior may prove problematic, although the overall risk is small. Decision has been made to keep heavy comments and code snippets if we were to revert back somehow to the previous situation. NOTE 2. Putting a context on a many2one field may change the value returned by `name_get` for that field. By default, the calls to `name_get` are done by `onchange`. If the context on a field must be used for `name_get`, one has to set the option `always_reload` to `True` on the field. In that case, every `onchange` that changes the value will trigger an extra `name_get`. NOTE 3. Suppose that a one2many field has a list view with field A, and a form view without field A. When adding a line, we now send all known fields (main view and inline views) to the `onchange`, which may return a default value for A. The value will appear on the list view, but not in the form view. The former behavior was to call `default_get` with the fields that occur in the form view only, and therefore field A would be left to value `False`. NOTE 4. A test surprisingly adds an extra call to `read`. The test was actually wrong before. With the changes in MockServer, we now correctly receive a command `[6, false, [1]]`, whereas before we received `[1]`, which isn't a valid command, and which was ignored. As a consequence, an extra `read` is done, whereas the test asserts it shouldn't. But it already didn't work before (I checked by sending the correct command). This needs to be bugfixed elsewhere (task-id-2323491): in a o2m with a onchange and default order records on an other page than the first should not trigger a `read`. Task 2261084 Co-authored-by: Raphael Collet <rco@odoo.com> Co-authored-by: Aaron Bohy <aab@odoo.com> 
This commit adapts the BasicModel to combine calls to `default_get` and
(first) `onchange`.  When creating a new record, we now only call
`onchange`, which thus return default values and potential onchange
values.

Tests (and the MockServer) have been adapted accordingly.

NOTE 1.  If the `default_get` within the `onchange` returns a value for
a field that is not in the view, we ignore it, and it won't be saved.
Before, that value was kept and sent upon save.  This change in behavior
may prove problematic, although the overall risk is small.  Decision has
been made to keep heavy comments and code snippets if we were to revert
back somehow to the previous situation.

NOTE 2.  Putting a context on a many2one field may change the value
returned by `name_get` for that field.  By default, the calls to
`name_get` are done by `onchange`.  If the context on a field must be
used for `name_get`, one has to set the option `always_reload` to `True`
on the field.  In that case, every `onchange` that changes the value
will trigger an extra `name_get`.

NOTE 3.  Suppose that a one2many field has a list view with field A, and
a form view without field A.  When adding a line, we now send all known
fields (main view and inline views) to the `onchange`, which may return
a default value for A.  The value will appear on the list view, but not
in the form view.  The former behavior was to call `default_get` with
the fields that occur in the form view only, and therefore field A would
be left to value `False`.

NOTE 4.  A test surprisingly adds an extra call to `read`.  The test was
actually wrong before.  With the changes in MockServer, we now correctly
receive a command `[6, false, [1]]`, whereas before we received `[1]`,
which isn't a valid command, and which was ignored.  As a consequence,
an extra `read` is done, whereas the test asserts it shouldn't.  But it
already didn't work before (I checked by sending the correct command).
This needs to be bugfixed elsewhere (task-id-2323491): in a o2m with a
onchange and default order records on an other page than the first
should not trigger a `read`.

Task 2261084

Co-authored-by: Raphael Collet <rco@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
 [IMP] web, *: improve mock server and replace most mail mockRPC 2020-08-13T16:26:35+00:00 Sébastien Theys seb@odoo.com 2020-08-13T16:26:35+00:00 c2918c139b8f1026b57a257fbb74570d7a224c98 Improve mock server: - add support for mocked `fetch` - add support for `active_test` - add support for x2m `in` in domains - add support for default values computed from a function - implement a more natural "next id" compute - allow initial data without ids - ensure write and x2m commands integrity - improve bad data/bad commands error messages - always warn for failing RPC, not only in debug mode - fix all existing tests that had inconsistency data Other changes done in mail (or dependents) that are not just related to tests: - remove `direct_partner` from formatter result ->`correspondent` can be computed from other keys, especially `members` - fix `livechat_visitor` convertData -> only process if there is value - add `current_partner` and `current_user_id` as `init_messaging` result -> easier to mock than session - remove usage of `need_moderation` -> that was just a search indirection to `moderation_status` - adapt `partner_id` -> `res_partner_id` key in `_notification_format` -> to be consistent with field name - add name in result of `mail_partner_format` -> sometimes display_name is not the same - remove usage of `is_moderator` -> that was just an indirection to `moderation_channel_ids` Enterprise counterpart: https://github.com/odoo/enterprise/pull/11523 task-2287171 closes odoo/odoo#55854 X-original-commit: 7ba3fecb3377a720d1eb70e7515a0c45da73836d Related: odoo/enterprise#12391 Signed-off-by: Sébastien Theys (seb) <seb@odoo.com> 
Improve mock server:

- add support for mocked `fetch`
- add support for `active_test`
- add support for x2m `in` in domains
- add support for default values computed from a function
- implement a more natural "next id" compute
- allow initial data without ids
- ensure write and x2m commands integrity
- improve bad data/bad commands error messages
- always warn for failing RPC, not only in debug mode
- fix all existing tests that had inconsistency data

Other changes done in mail (or dependents) that are not just related to tests:

- remove `direct_partner` from formatter result
  ->`correspondent` can be computed from other keys, especially `members`

- fix `livechat_visitor` convertData
  -> only process if there is value

- add `current_partner` and `current_user_id` as `init_messaging` result
  -> easier to mock than session

- remove usage of `need_moderation`
  -> that was just a search indirection to `moderation_status`

- adapt `partner_id` -> `res_partner_id` key in `_notification_format`
  -> to be consistent with field name

- add name in result of `mail_partner_format`
  -> sometimes display_name is not the same

- remove usage of `is_moderator`
  -> that was just an indirection to `moderation_channel_ids`

Enterprise counterpart: https://github.com/odoo/enterprise/pull/11523
task-2287171

closes odoo/odoo#55854

X-original-commit: 7ba3fecb3377a720d1eb70e7515a0c45da73836d
Related: odoo/enterprise#12391
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
[FIX] web: trying to create record based on name_create w/o _rec_name 2020-07-09T12:43:36+00:00 Joseph Caburnay jcb@odoo.com 2020-07-06T14:19:26+00:00 259cf453463448fdd25b5d29f45e0d3e8eb18382 There are orm models that don't have _rec_name defined. The orm doesn't allow creation of record via name_create if _rec_name is not defined in the model. This commit considers this fact, such that if name_create returns false, we don't proceed on displaying the non-existing record. Note: _rec_name defaults to 'name' if not specified so only few models don't have _rec_name. closes odoo/odoo#54270 Task-id: 2285036 X-original-commit: 676c2b8e4fdf7347d44bc5afb7ca51d39338a527 Signed-off-by: Aaron Bohy (aab) <aab@odoo.com> 
There are orm models that don't have _rec_name defined. The orm doesn't
allow creation of record via name_create if _rec_name is not defined in
the model. This commit considers this fact, such that if name_create
returns false, we don't proceed on displaying the non-existing record.

Note: _rec_name defaults to 'name' if not specified so only few models
don't have _rec_name.

closes odoo/odoo#54270

Task-id: 2285036
X-original-commit: 676c2b8e4fdf7347d44bc5afb7ca51d39338a527
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
[FIX] *: adapt tests to env rework 2020-06-12T09:47:48+00:00 Aaron Bohy aab@odoo.com 2020-06-05T09:18:14+00:00 b4ba0fc34082deec8ca6c871ce7a203c0a3a61a4 This commit adapts tests following recent changes on the helpers. The main change is that addMockEnvironment (and all functions using it) are now async, as they need to wait for services to be started. 
This commit adapts tests following recent changes on the helpers.
The main change is that addMockEnvironment (and all functions using
it) are now async, as they need to wait for services to be started.
 [IMP] web,*: highlight quick create feature to user 2020-06-10T13:08:33+00:00 Dhruv Patel dhp@odoo.com 2020-06-03T10:35:33+00:00 eacbec1e03b1f25e71875fb7caed646a53af67ed Generally, Users are not necessarily aware that they can quick create a most records by simply typing in their name+enter in the many2xxx field input. The exact purpose of this commit is to make sure the user discovers the quick create feature of our many2xxx fields. For that, when the input is empty, display 'Start typing to create a record...' at the bottom of the dropdown when can_create is set and no_create_edit option not set. So the user can easily understand that by typing and pressing enter will create the new record. Also "Search and Create" options in the dropdown only been shown to the user when it type anything in the input box as the same case in the "Create" option. Task : 2266557 Co-authored-by: Mohammed Shekha <msh@openerp.com> Co-authored-by: Julien Mougenot <jum@odoo.com> 
Generally, Users are not necessarily aware that they can quick create a most
records by simply typing in their name+enter in the many2xxx field input.
The exact purpose of this commit is to make sure the user discovers the quick
create feature of our many2xxx fields.

For that, when the input is empty, display 'Start typing to create a record...'
at the bottom of the dropdown when can_create is set and no_create_edit option
not set. So the user can easily understand that by typing and pressing enter
will create the new record.
Also "Search and Create" options in the dropdown only been shown to the user
when it type anything in the input box as the same case in the "Create" option.

Task : 2266557

Co-authored-by: Mohammed Shekha <msh@openerp.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
 [FIX] web: resquencing stop at first controller 2020-05-27T16:56:19+00:00 Nicolas Lempereur nle@odoo.com 2020-05-25T14:41:42+00:00 9d40ec7d15898ee9f3d2a92c7264690586c35cd8 When a resequencing is done inside an object hierarchy of two controllers, since 9b90d8727d we would call resquencing code one time per controller. So if for example we are in a list view inside a form view (eg. a "Search More" modal in a form view) the resequencing would work for the list view, but then cause traceback when it is handled by form view. With this changeset, the first controller that get the event `resequence_records` even gobbles it up. Without change, added test fails because of original traceback: Cannot read property 'res_id' of undefined@ 202 ms Source: TypeError: Cannot read property 'res_id' of undefined at /web/static/src/js/views/basic/basic_controller.js:744:67 ... opw-2256818 closes #51827 closes odoo/odoo#52018 X-original-commit: eef4b99fdb9469c040af80d055933eda367b7b3d Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com> 
When a resequencing is done inside an object hierarchy of two
controllers, since 9b90d8727d we would call resquencing code one time
per controller.

So if for example we are in a list view inside a form view (eg. a
"Search More" modal in a form view) the resequencing would work for the
list view, but then cause traceback when it is handled by form view.

With this changeset, the first controller that get the event
`resequence_records` even gobbles it up.

Without change, added test fails because of original traceback:

  Cannot read property 'res_id' of undefined@ 202 ms
  Source:
   TypeError: Cannot read property 'res_id' of undefined
    at /web/static/src/js/views/basic/basic_controller.js:744:67
   ...

opw-2256818
closes #51827

closes odoo/odoo#52018

X-original-commit: eef4b99fdb9469c040af80d055933eda367b7b3d
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
[FIX] web: failing quick create in m2o inside x2m 2020-05-08T15:38:06+00:00 Aaron Bohy aab@odoo.com 2020-05-08T12:17:26+00:00 8000e895cd33cb622919fe6f48934cb692728bc2 Write something in a many2one field, and click on 'Create "..."' to quick create a record with the given value (name_create). When the name_create fails (e.g. because there are mandatory fields in the model), we open a form view. Before this commit, when this happened for many2one fields inside x2many editable lists, it crashed, since [1]. [1] 50bf8309f88fb6c8d8e27b14d40450e92e5a4e4e closes odoo/odoo#50948 X-original-commit: 43c513306094444ff25ad98584b426ddb8a3b525 Signed-off-by: Julien Mougenot (jum) <jum@odoo.com> Signed-off-by: Aaron Bohy (aab) <aab@odoo.com> 
Write something in a many2one field, and click on 'Create "..."'
to quick create a record with the given value (name_create). When
the name_create fails (e.g. because there are mandatory fields in
the model), we open a form view.

Before this commit, when this happened for many2one fields inside
x2many editable lists, it crashed, since [1].

[1] 50bf8309f88fb6c8d8e27b14d40450e92e5a4e4e

closes odoo/odoo#50948

X-original-commit: 43c513306094444ff25ad98584b426ddb8a3b525
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
[IMP] web: FieldMany2one: reword and simplify dialog 2020-05-05T15:19:45+00:00 Dhruv Patel dhp@odoo.com 2020-04-14T12:08:34+00:00 a599f1402e937dfa869774f3e8345c0c645425fd This commit improves the dialog that opens when a user clicks out of an 'un-commited' many2one. It is no longer possible to edit the value, and the sentence has been reworded. closes odoo/odoo#49528 Task: 2234212 Signed-off-by: Aaron Bohy (aab) <aab@odoo.com> 
This commit improves the dialog that opens when a user clicks out
of an 'un-commited' many2one. It is no longer possible to edit
the value, and the sentence has been reworded.

closes odoo/odoo#49528

Task: 2234212
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>