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>

With this commit, it is now possible to display sample (fake)
data in empty views, in the hope of easing user onboarding.
This can be enabled (in list and kanban views) with attribute
sample="1" on the arch root element. In this case, if there is
no data to display, sample data will be generated based on
heuristics (depending on field types and names). This can be
used in addition to the no content helper.

Task 2232801

X-original-commit: 7c8e627ff5029cb539d702705e5ce53d658c76ed
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Jérémy Hennecart <jeh@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>

This commit refactors the way the decoration-xxx attributes are
applied to field widgets/components, in a way that it can be
overridden in a given field or component to generate the approriate
className. By default, 'decoration-x' applies className 'text-x'.

This will be necessary for the new 'FieldBadge' component, which
needs to apply 'bg-x' classNames instead of 'text-x'.

Part of task 2195254

There's a traceback when we edit an activity on a campaign

  * Create a child activity
  * Save the activity (not the campaign)
  * Edit again the activity
  * -> Traceback

Introduced in a9cebd5

Task ID 2220930

closes odoo/odoo#49698

X-original-commit: efa8952c39b0bcb0969013dc22e05b5d61ff1c66
Related: odoo/enterprise#9964
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

* account

This commit adds a new field registry for component fields.
This field registry is used to only register the new field components
and the other one should register the legacy fields.
Those two registries will be used together while all legacy fields are
not converted to owl component.

As the legacy registry now throws an error when adding a component
field the existing component fields (account.ShowGroupedList and
account.ShowResequenceRenderer) are moved into the new registry.

This commit also refactors some field managers (form renderer, list
editable renderer, calendar popover) to use the new registry and thus
support the component fields.

task id: 2193996

Let's assume a form view with an x2many list, containing itself
an x2many field (no widget, so simply displaying the number of
records). When a record of the list is clicked, a form view
opens and displays the same sub x2many field, with widget
many2many_tags. Both list and form views of the x2many aren't
inline (thus have to be fetched on demand).

Before this commit, it crashed when the user clicked on a row
of the x2many list.

The bug has been introduced by a9cebd5a, which wrongly removed the
code handling this specific situation. At least, now we have a
test attesting that this code isn't useless.

Note that the diff isn't as scary as it looks like (we just added
an if/else, and thus indented the former code inside the else
clause).

closes odoo/odoo#48116

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

Let's assume the following scenario in a form view:
 - have a one2many field, say fieldA, displayed as a list,
   containing another one2many, fieldB, (no widget, thus
   displaying 'n record(s)')
 - the one2many list is not editable, so there is a sub form view,
   displaying fieldB as a list, and in this list some random field,
   say fieldC, is displayed
 - have a random field on the main form view, with an onchange to
   populate the one2many
 - set that random field s.t. the onchange returns something like
   fieldA: [[5], [0, 0, {fieldB: [[0, 0, {fieldC: 'value'}]]}]]
 - there is now a record in fieldA's list, displaying '1 record'
   as value for fieldB
 - click on that record to open it in a form view (dialog)
 - in the dialog, in fieldB's list, we expect to have a single row
   displaying 'value' as value for fieldC

Before this rev., it crashed when opening the record in the dialog,
whether the form view was inline or not.

The crash occured because fieldB was already in the list view, so
datapoints already existed for it (a list datapoint, and record
datapoints for records in the relation, in our example one record
datapoint). However, those datapoints didn't have the fieldsInfo of
the form view. When opening the form view, we added the fieldsInfo
of the form to the datapoint of the record we opened, but we didn't
recursively apply the fieldsInfo to its children. As a consequence,
when rendering the list view for fieldB in the dialog, we haven't
the information about fieldC, and it crashed.

Note that if fieldB wasn't present in fieldA's list view, it worked
fine because datapoints didn't exist before we opened the record in
the dialog.

Task 2120235

While x_name has long been automatically supported as an equivalent
of name, x_active was not.

This commit adds this behaviour OoB, both in the ORM and the web client.

On the ORM-side, a new `_active_name` attribute is supported on models.
This attribute specifies the field that should behave as an active marker
for records of the model. It is supported the same way `active` has been
until now (filtering by the `active_test` context key and toggled by the
`action_archive`, `action_unarchive` and `toggle_active` methods).
Although no check has been added on the field's type, it is assumed to
be a boolean field (the same way no check is present on the `(x_)name`
field).

On the client-side, the list view and form view now both support
detecting the presence of either `active` or `x_active` on records,
automatically adding an '(Un)Archive' button in the Action menu if such
a field is detected.

Note that the ORM implementation does actually need the field to be named
in any specific way, but since the web client has no mechanism to load
information regarding a model (the lifecycle of an action loading
includes loading the action, view and record(s) but no generic
information about the model itself besides what is included in the
views), we restrict the field's name to `(x_)active` to avoid confusion
as any other name would work at the ORM-level but not in the client.

In the future, the client might be able to more elegantly get
information about models, but this was not the scope of this change and
this solution should cover most cases.

Note that the `active` field will always takes precedence over the
`x_active` field to avoid confusing the polarity, even if both fields
are present on the model.

In the case of a custom field, it might be slightly annoying that the
default value of a Boolean field is `False`, which means that upon
adding the column, all existing records are automatically archived. This
can easily be worked around using an `ir.default` record for that
particular field and an update of existing records (e.g. through the
list view). The goal of this change was not to make it easy to add
support for custom active fields, but to make it possible - we have
therefore kept this implementation which introduces few changes while
adding enough flexibility for developers.
See https://twitter.com/zubair_shafiq/status/1202587553871880192?s=20
for more info regarding supporting any `_active_name` in the web client.

Co-authored-by: Raphael Collet <rco@odoo.com>

1/ Write a form view with a o2m field that has its own inline tree view
(no other view exist in db for the target model)
2/ Open that view in a mobile environment
3/ Instead of having a list view, you get a kanban view. No luck for
you, since the default kanban generated by `models.py` is an empty one,
your records are *invisible* \o/

From what I can tell, the previous condition made no sense:
```
if (there is a list view and a kanban view)  <-- this seems absurd
  then (use the list mode)
elif (there is no list view but a kanban view)
 then (use the kanban mode)
else (use both modes)
```

The first condition seems absurd: it *actively* ignores a kanban view
if there is one. Even better, the list view whose existence it checks
is never there: it checks for a `tree` when it should be checking for a
`list`. In short, the first condition was *never* met, and you ended up
either with exclusive kanban mode or with both modes - even if you had
no existing kanban view for the target model...

This commit moves the normalization of `tree` into `list` before
attempting to process the x2many field's subviews. It clarify the usage
of `tree` vs `list` (cf. only use `list`) which  prevents weird edge
cases like described above.

closes odoo/odoo#36237

Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Co-authored-by: Adrien Dieudonné <adr@odoo.com>
Co-authored-by: Pierre Paridans <app@odoo.com>