The changed test uses the drag&drop helper, and an operation does
not work as expected with the given params on chrome 90. The runbot
currently uses chrome 80, so it is not an issue, but if your chrome
is up-to-date, and you try to run the test suite, this test would
fail.

closes odoo/odoo#70008

X-original-commit: 43994da9980e4133274984f720bb58f3546ea0f9
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>

Commit [1] recently fixed an issue with nested x2many fields and
onchanges: in some cases, all field values weren't sent to the
server as they should.

However, there is a small issue with this fix. We didn't correctly
apply the default value to option `changesOnly`: when not given,
it was considered false, whereas in this particular function it
should have been true.

It caused an issue in the following scenario:

Have a form view with an x2many field (say A) displayed as a list.
In the list, there is another x2many field (say B), and (whatever
its type) a field C with an onchange. When the user changes C, the
onchange is performed, and we send to the server the value of all
fields. In particular, in the row, we send the value for the
many2one field pointing to the main record (the inverse field of
the x2many relation). The value for that field is basically the
whole record, containing itself field A. For field A, the value is
a list of commands, and for the updated record, it is a command 1.
Before this commit, in the values sent for this command, field B
was the empty array, even if it wasn't empty.

This issue was reproducible in account.move, on an existing record
having already a line in invoice_line_ids (this is field A). In
that line, tax_ids (this is field B) must have a tax which is
included in the price. When changing the quantity of the product,
the subtotal wasn't correctly computed.

[1] https://github.com/odoo/odoo/commit/a8b43d02066b2299ac2f4b88056c37725e9ce6cd
opw~2489755

closes odoo/odoo#69167

Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>

One might design a custom field widget to display/interact with a
one2many field. Before this commit, if this field widget triggered
a field_changed event to update a related record, it crashed,
because the code assumed that there was a view associated with the
field.

Closes #68276
opw~2468238

closes odoo/odoo#68294

Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>

Let's assume the following situation. We have a form view with a
one2many field A displayed as a list. In the list, there is a
one2many field B. B can't be edited, its value is computed by
an onchange. By default, it contains a single record (i.e. the
first value returned by the onchange is [[5], [0, 0, {...}]]).
When another field (say C) changes, B's value is re-computed to
[[5]]. Moreover, there is an onchange on A.

In this form view, let's assume the following scenario. Create a
new record and add a line to A. In this new line, B already
contains a record. Change C. This triggers an onchange that
returns [[5]], and B is now empty. It triggers a second onchange,
on the main record (as field A changed).

Before this commit, in this second onchange, B's value wasn't sent
among the other values of the new line.

The spec says that for onchanges, we must send all data, not only
what has really changed. From that perspective, the above scenario
highlights an issue.

That issue had two root causes. First, commit [1] wrongly fixed
another issue, and as a consequence, when building what to send
for the onchange, we didn't generate the values for fields that
hadn't changed inside an x2many (for added subrecords at least).
This commit reverts the fix of [1], and fixes it differently by
only sending a command 1 (update) after a command 4 (link to)
when the record is dirty (i.e. when it has been modified). See
[1] for context and details.

Second, the code that generates the values to send to onchanges is
the same as the one that generates the values to save records
(write or create). However, when saving, we only send what has
really changed. The values are at some point processed to remove
empty command lists from the list of changes (as it means that
nothing changed). However, here we ignored the flag that stated
whether we want all field values or just what has changed. This
commit takes the flag into account before removing the field's
value.

[1] https://github.com/odoo/odoo/commit/3e3a244e1afc4d74920a6302a14fa2590e8b6648

Issue reported in task~2352524
  Model: account.move
  One2Many (A): account.move.lines
  Nested computed One2Many (B): tax_detail_ids
  Field triggering the onchange (C): tax_ids

closes odoo/odoo#67679

Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Co-authored-by: Géry Debongnie <ged@odoo.com>

Steps:
- Install mrp
- Go to Manufacturing > Master Data > Bills of Materials
- Create a BoM
  - Components:
    - Add a component
- Save
- Click the component
- Close the modal window
- Click the component once more

Bug:
Traceback here:
https://github.com/odoo/odoo/blob/55a6642a9621fa9683895d5d45a015bb04c3017b/addons/web/static/src/js/views/basic/basic_view.js#L147
Error: can't convert undefined to object

Explanation:
As seen on the line just above:
https://github.com/odoo/odoo/blob/55a6642a9621fa9683895d5d45a015bb04c3017b/addons/web/static/src/js/views/basic/basic_view.js#L146
`fieldsInfo` might not have the view we are looking for.

opw:2452142

closes odoo/odoo#65805

X-original-commit: b27c0698d95cbccaa6c35a1fd3faa852a71ac2c2
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: backspac <backspac@users.noreply.github.com>

This commit partially reverts commit [1], and backports commit
[2] from 14.0.

Even though [1] correctly fixes the faulty scenario, there is a
variation of this scenario which isn't handled. It has been
fixed in 14.0 by [2], and that fix also fixes the original
issue of [1]. So we keep the tests of both [1] and [2], and
the fix of [2].

[1] dd97d446ee94a32089f200bb7122139d31e69873
[2] f6c06bd0b87dac11d76a3134eb61c7ef4eb59270

closes odoo/odoo#65562

X-original-commit: 63c60549ef5185f5ec61dc985f0bcc2cb82ccc89
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>

Let's assume the following situation: in a form view, there is a
one2many field A displayed as a list (non editable). In the list,
there is another one2many field B displayed with no widget (it
basically displays "X records"). In A's form view, B is also
displayed, but this time as a list.

There is an onchange on the main form view that adds a line in A,
(and simply sets B to [[5]], i.e. 'No record').

Before this commit, if the user opened the newly added sub record in
A, and clicked on 'Add a line' of B, it crashed.

The cause of the crash was that the wrong viewType was used to
create the new (default) record in B: it used the original
viewType, which was undefined (B is displayed with no widget in
A's list). With this commit, we use the viewType of B that is used
to edit it, in this case 'list'.

In the slighlty different scenario where B is displayed with
widget many2many_tags in A's list, there were no crash, but wrong
fieldNames were sent to the 'default_get' RPC. As a consequence,
default values for fields in B's list were potentially not loaded.

opw-2422806
closes #64793

closes odoo/odoo#65157

Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>

Let's assume the following scenario with 'purchase_product_matrix'
module installed:
 - create a new Purchase Order
 - add a line in the one2many
 - select "Customizable desk" as product
 - [the desk matrix opens]
 - close the matrix
 - select "Conference chair" instead
 - [the desk matrix opens, whereas it should be the chair one]

It didn't work because of a small bug in the FieldOne2Many. This
field is configured to be reset when any other field in the view
changes. The product configurator feature relies on that. However,
when another field changes, the One2Many didn't update its internal
state with the new record (and it skipped the rendering, which is
fine). The matrix product configurator thus read an obsolete value
in the internal of the one2many.

Since the internal state is now always up-to-date, we can directly
read there the grid information, instead of looking inside other
fields that have been updated (attempt done in [1])

It would be nice to rethink the whole product configurator stuff
in master, to make it more robust, maybe when converting it to owl?

[1] https://github.com/odoo/odoo/commit/21bcafc053be7f80eed7a684fee2dc1e3caaafa5

opw~2421798

closes odoo/odoo#64552

Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>

Consider the following situation:
 - have a form view with an x2many field displayed as a list
 - the x2many field has a form view that contains an x2many field,
   which isn't in the list
 - for that x2many field, we can also open a form view to see/edit
   the related records.

As the x2many field isn't in the list, when we open a subrecord, we
modify the fieldsInfo to add the information about the x2many field
we didn't know before. Doing so automatically applies raw changes
that we might have stored earlier (from onchanges) for that field,
 because we couldn't apply them before knowing the type of that
field.

Before this commit, the function that applies the raw changes was
called recursively on the dataPoint and all its children (thus on
the x2many list datapoint), which produced a crash as this function
is designed to work on dataPoints of type record.

Actually, calling it on sub datapoints is useless, as it properly
works recursively, and applies raw changes on x2many fields itself
when necessary.

This commit ensures that we don't call this function on list
datapoints anymore.

Closes #62334
OPW 2389991

closes odoo/odoo#62399

Signed-off-by: Géry Debongnie (ged) <ged@openerp.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>