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>

A previous commit (8dbd1efef899fb637acca3c318ae99cb23838b8f) fixed a
part of the basicmodel that used _.each to iterate on an object with
field names as keys, which does not work when a field is named "length".
To fix it, I simply used a native for ... in statement.  However, I
missed the fact that there was a second 'return' statement in the body
of the closure given to _.each, so the onchange method returned
prematurely.

The fix is to simply use the continue statement in that case.

closes odoo/odoo#67228

Signed-off-by: Aaron Bohy (aab) <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>

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>

This commit handles 2 things:

1) the merging of the `py_utils.context()` into the evaluation context
returned by `BasicModel._getEvalContext` to access the same time-related
keys,

2) the addition of 2 new keys into the `py_utils.context` (thus
transmitted to the basic model): `today` (an alias for the already
present `current_date`) and `now` which represents the current date and
time value.

Task 2269697

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 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.

Before this change, fields.Reference displayed into the popover of
a calendar view was always empty. This was because the popover view
generated from a double click on an element in the calendar view
creates its own recordModel in JS and the function to create this
record did not handle the reference field case.

This commit detects if a reference field is defined into the record
and adds the necessary processing to process its value and creates
the corresponding dataPoint.

opw 2151635
Closes #41262

closes odoo/odoo#42707

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

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>

Steps to reproduce:

1. Go to the Accounting / Invoicing apps
2. Open Taxes (Configuration -> Accounting / Invoicing -> Taxes)
3. Try to create a new tax and the client crash.

It occurs because the `_processX2ManyCommands()` method doesn't handle
correctly a missing `fieldInfo` on some X2Many tags.

On mobile, when calling `load_views` the kanban view is used by default.
But if the kanban isn't defined, a default kanban view with only the id
of the model is used.

In the case of the taxes form, the `default_get` retrieved for this
form refers to a Many2Many (`tag_ids`) inside a One2Many. But this field
isn't present inside the loaded kanban view, so when we process the
command defined by the `default_get`, the `field_view` item doesn't
exist (because the default kanban loaded only contains the id of the
field).

Now instead of using an undefined `fieldInfo`, we fall back to an empty
object on the missing field to avoid the crash.

closes odoo/odoo#40617

X-original-commit: 47a306a31ac6d3c9e68e83b77a80426d5c6ceb05
Signed-off-by: res-odoo <res-odoo@users.noreply.github.com>