This commit fix the "Unsupported M2M command 1" raised `Form` helper.

The `onchange()` method will in fact emit UPDATE command for many2many
fields when the value submitted an the one in database has changed
(this is the case for example for nested m2m in form views)

OPW-2044631

closes odoo/odoo#59937

X-original-commit: 76bd8208a416cefab6becff9f2d7204c7d196201
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Xavier ALT <xavieralt@users.noreply.github.com>

The Form class already handles cases for attrs that contain boolean
values, e.g.:
`attrs="{'readonly': True}"`

But it doesnt for integers, e.g.:
`attrs="{'readonly': 1}"`

This commit changes the expected non-domain value from boolean to
integer, because both are valid cases and the former is a subset of the
latter.

[1] https://github.com/odoo/odoo/blob/b3d4938ba6b1/addons/repair/views/repair_views.xml#L54

closes odoo/odoo#56609

X-original-commit: 782534a429f10e7b114c838687d38aa4080a920c
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Luis González [Vauxoo] <luisg123v@users.noreply.github.com>

When creating a new record, the client calls `default_get()`, completes
the returned values with `False`, and calls `onchange()` to apply the
onchange to the defaults.

Optimize the double round-trip by integrating `default_get()` inside
`onchange()` for the first call.  The method is called with an empty
list of fields, and usually no field values, except for records in a
one2many field.  In this case, `onchange()` does both steps above.

Task 2261084

Issue is specifically in the case of an onchange removing a record in
an o2m in an o2m (so a sub-o2m) if loading an *existing* record in the
SSF: since the server pretty much only returns a REMOVE_ALL followed
by the records to keep or create, conserving the removal information
requires diffing the value currently stored in the form and the result
fo the onchange.

Diff which was properly done for top-level o2ms, but not for the ones
below that (apparently forgot this bit when improving support for
nested o2ms earlier this year).

X-original-commit: 177d009541cca589c6ebb85fc051b893ec001536

Search the xsd files from in the database.
To enable this option, the Environment should be passed to the optional
`env` parameter. Both the XSD root and the XSD imported by the root and
the recusrively imported files will be searched in the database.

X-original-commit: 06a35f2e11230db81b8c21696d228097b31cf649

The SSF had pretty much punted on nested o2m as that's... not usually
a concern because few people are insane enough to put o2ms in their
o2ms in their views. And also because even if somebody did, sometimes
nothing would break because it turns out to be pretty difficult to
actually get into *using* those things.

MRP managed to do it though, and repro-ing required copying over parts
of mrp.production and then understanding why it didn't fail:

* obviously needs an o2m (f1) which contains an o2m (f2), in the
  view (an invisible tree inside a visible tree)
* needs an onchange which somehow updates the sub-o2m
* needs to actually trigger an onchange on the root form for f1,
  meaning f1 must be a dependency of a compute field or something (here
  I just marked every damn field as on_change as the optimisation of
  "don't call onchange when there's no need to" doesn't matter)

Also needs to be working on an existing record with existing
lines *and sublines* as the issue occurs with records to update.

The issue here is that `_onchange_values` would clean up f1 e.g. send
nothing for unmodified entries, and only send modified fields
otherwise, but it would only do so for the toplevel, meaning the
sub-level would not go through this step, and could send UPDATE
commands with an `id` field (set to the original value but
still). This would then proceed to blow up while loading the record,
as id fields are not writeable.

The fix is to perform `_onchange_values` recursively. Do that using a
separate helper in order to avoid blowing up on override and whatnot,
or faffling about with weird branching to get the "default" values in
case they're not provided, the root function can get all the relevant
bits and call the helper with them, then the helper does that setup
internally and calls itself directly.

An other issue I stumbled upon when investigating is a similar problem
on *save*, due to an implementation detail of the SSF: UPDATE commands
are fetched lazily.

`_values_to_save` took care of "hydrating" all update commands (and
validating and filtering them) of modified o2m fields, but as it would
not do so recursively a modified f2 would not get properly hydrated
and filtered, and could try to write `None` onto existing records.

closes odoo/odoo#51350

X-original-commit: 3dfb4cfad849936748cc6a5b8f712e100461a86f
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>

Purpose
=======

The current kanban view is messy. It is difficult to identify which
apps are installed or not. The user can completely miss a module
that might have interested him. A search panel would make things way
more readable.

closes odoo/odoo#44401

Taskid: 2181557
Related: odoo/enterprise#8144
Related: odoo/upgrade#879
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>

In the SSF, o2m updates get initialized with no values (1, id,
{}). The record data is only fetched when the "record" gets updated
explicitly from which updates will hopefully get properly tracked &
saved.

However if the "record" was first initialized through an onchange
values which are updated by the onchange (diverging from the db) those
would not get tracked and thus wouldn't get saved when the record is
saved.

* use more specific placeholder (None) for "o2m records to update but
  we don't have values yet"
* once we have values, always store them as an update-tracking dict
* if we don't have values yet for an o2m and an onchange is trying to
  write to it, initialize with values from database first (might
  eventually be a good idea to initialize upfront though there's the
  question of what happens for default values and recursive views)
* mark anything coming back from the onchange and differing from local
  values as changed (so they get sent out on save)
* properly reify parent values for onchange instead of sending them
  as-is
* the evaluation context for contexts (and domains) needs properly
  formatted values so use `_values_to_save` to get them, however it
  cares about neither required-ing nor filtering out e.g. unmodified
  fields, therefore add an awful toggle to handle this

Task 2150302

Probably todo in the future:

* better UI for change-tracking dict, should have "snapshot"
  support (to freeze / discard previous changes)
* cleanup save, it's unclear that it properly resets the form

closes odoo/odoo#43235

X-original-commit: 6c99fe3ffec3aeb8d210e3b943ccef81d62d44ce
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>

m2ms are internally represented as "6" commands, however in domains
it's possible to compare an m2m value to a list of ids (to
investigate: whether this is an artifact of internal webclient repr or
part of the real contract).

Add a workaround in SSF modifier computation to convert the m2m
command storage to a simple ids list.

A better fix would probably have been to represent the m2m as a list
of ids internally (and only convert on load / save) however it not
completely trivial as it has to be done recursively in order to
properly handle an m2m inside an o2m. So it's a complete change of the
internal data model (which should probably go alongide more
fundamental changes e.g. properly handling parent refs, etc...)

Also add very minor support for widgets (mostly so it's possible to
set widget=many2many on an o2m field).

closes odoo/odoo#39467

X-original-commit: 927979beff9e5d4f6c88078862779eaa88f4e07d
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>