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>

Commit [1] altered the way the FieldMany2Many behaves with respect
to 'create' and 'delete' options. Indeed, for many2many fields,
adding or removing records doesn't mean "creating" or "deleting"
records, as it is only about adding/removing records to/from a
relation. This is completely fine and correct.

Unfortunately, a feature has been lost in the process: it is no
longer possible to state that a many2many field should be editable
but should not allow to add (or remove) record to the relation.

This commit fixes the issue by adding two new options: 'link' and
'unlink' for that purpose.

[1] https://github.com/odoo/odoo/commit/c98579d25af01c14df4baf57fb4652f3e7469096

opw~2466213

closes odoo/odoo#67358

Signed-off-by: Lucas Perais (lpe) <lpe@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>

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>

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>