The Many2ManyCheckboxes widget displays all values that could be
in the many2many relation, with a checkbox indicating whether each
value is in the relation or not. It is designed to be set on fields
where the comodel contains a few records (typically, we don't want
to see dozens of checkboxes in the form view). This widget shouldn't
be used on many2manys with a large comodel, as we have better tools
to handle them (like a tree view).

We deal with extreme cases (when the widget is, by mistake,  set on
a field where the comodel is huge) by using the name_search limit
of 100: at most 100 checkboxes are displayed.

Before this commit, this extreme situation wasn't correctly handled.
If there were in the relation records that weren't displayed
(because they weren't inside the 100 limit), then, editing the value
by (un)selecting a checkbox would automatically remove all non
displayed values from the relation.

This commit ensures that we keep in the relation all values that
aren't displayed.

Issue spotted when working on opw~2439041

closes odoo/odoo#67373

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

The support for "active_test" context key has been introduced in c2918c1
However, the context key is ignored in many mocked ORM methods (if not all).

This commit adds support for the `search` and `search_read` methods.

Note: this is done to easily write some tests in odoo/enterprise#16363
and it might be usefull to test futures features (or fixes) using this
context key.

closes odoo/odoo#66190

Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>

The mock implementation of `name_get` does not fully reflect
the real server implementation.

The real implementation is described in tests added in
this commit.

Note: in my wildest dreams, the mock server tests would be run
against the real *and* the mock implementation to ensure they
do not diverge.

closes odoo/odoo#62347

Related: odoo/enterprise#14990
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>

Also fix an issue with livechats not being considered in 'chat'
filter of messaging menu.

Task-Id 2282426

closes odoo/odoo#58466

X-original-commit: 631e52536964763bbfe857305f023e5e67084e95
Signed-off-by: Sébastien Theys (seb) <seb@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 introduces a new semantics to define action and method buttons
in the list view.
The aim of this feature is to be able to do some actions on selected records, or on the entire
records' domain with the help of buttons located in the controlPanel, much like the form view header buttons.

To define such buttons, one must add a `header` node in the list view's xml definition
```
<tree>
  <header>
    <button type="action|object" name="actionId|methodName" string="button's text" context="{}"/>
  </header>
  <field name="fieldName" />
</tree>
```

task-2246383

The counters for categories were not updated when filter values were
selected. This commit fixes that situation.
This might impact the global performances of the search panel but
there is still room for improvement. Actually, it could be
possible to reload categories and filters less often by carefully
track the internal changes and the categories/filters attributes
(enable counters, expand,...).

closes odoo/odoo#49307

Related: odoo/enterprise#9795
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>

In the search panel, the domain used to compute the field image values
(when the attribute expand is false) was the same as the domain used
to compute counters (if enabled). The idea was that a value bringing an
empty domain is totally useless and should not displayed.
That being true, it turns out that if one does not allow them and
several fields are used, selecting a value in the search panel will very
often totally transform the search panel. From a UI perspective,
this turns out to be bad: the search panel 'moves'.
Let us give an example:
Let us start from a search panel that looks like to:

first_field
    A  1
    B  3
second_field
    C  1
    D  2 <--- mouse above D
    E  1

with first_field and second_field both with expand="0" and
enable_counters="1". Let us also assume that no record in the global
domain has both first_field=A and second_field=D.
Click on D would make the search panel look like to something like

first_field
    B  1
second_field
    C  1
    D  2
    E  1 <--- mouse here

(the selection of D does not impact the values for the second_field but
does for the other first_field values).

This has led us to use basically only the domain comming from
outside of the search panel to compute field image values.

This means that we might now have value with zero count even if expand
is false. In the above situation, a click on D would give us

first_field
    A
    B  1
second_field
    C  1
    D  2 <--- mouse still above D
    E  1

Task ID: 2154749

Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>

This commit introduces a new attribute 'limit' for search panel fields
that allows to avoid performance issues. That integer attribute (with
default 200) allows to fix a maximal number of values to display for the
fields. When the number of field values to display reaches the limit,
no values will be displayed. Instead, a warning message will be shown
in the corresponding search panel section.
Note it is possible to have no limit using limit="0" on a field.
This commit reintroduces in a better way the principle brought by the
fix 8d57153b34c04952a85f6642951cb2697016da84.

Task ID: 2154749