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>

Before this commit, if the widget "many2many_checkboxes" was set on
a field with more than 40 values in the comodel (i.e. more than 40
checkboxes displayed), (un)selecting a checkbox that wasn't in the
first 40 checkboxes crashed. This was due to the default x2many
limit of 40: we only created a datapoint for the first 40 values,
whereas we could have up to 100 values to process (name_search
server-side limit). Note that this limit of 40 had no other impact
than limitating the number of records processed by the BasicModel,
the maximum number of checkboxes displayed being ruled by the
name_search server-side limit.

This commit ensures that all values returned by the server (at most
100 when this message is written) are processed and can be edited
as expected.

opw~2439041

X-original-commit: be5e5bc49cb9744c26ca75dcee74caf11447f250

The ControlPanel has been converted in Owl [1], and the code using
it has been adapted accordingly. However, in the FieldX2Many, we
didn't properly wait for the ControlPanel to be updated (an update
of the ControlPanel was synchronous before owl, and is now async,
like every Owl renderings, as it waits for the nextAnimationFrame).

As a consequence, we might have tricky issues because the mounted
hook of the control panel might be called multiple times for a
single call to willUnmount later on. In mobile, we bind a global
event handler (on scroll) in mounted, and unbind it in willUnmount,
so we had leftover event handlers, that crashed when called after
the ControlPanel was destroyed. Note that even if the issue popped
in mobile, calling mounted on already mounted Components isn't a
good idea, and this should be fixed anyway.

The issue could be reproduced for instance in FieldService (with
collaborative pads activated in Project), in mobile, by opening
a task in Edit mode. Then, you might get a traceback by scrolling
after having discarded the edition

Here is a description of what technically happened:
 - when clicking on Edit, all widgets (including the FieldX2Many
   are destroyed and re-instantiated in 'edit' mode).
 - the pad widget directly triggers a field_changed event which
   causes a reset of the FieldX2Many (i.e. 'render' is called
   again)
 - the FieldX2Many detects that it already has a renderer (and a
   ControlPanel) so it updates them
 - it first updates the renderer, and when it's done, it updates
   the ControlPanel BUT doesn't wait for its promise, so the
   promise returned by that call to 'render' in FieldX2Many is
   resolved before the ControlPanel is actually updated
 - note that at this point, all thoses new widgets are not in the
   DOM yet
 - when all widgets are ready, the renderer patches the view (i.e.
   the former content is removed from the DOM, and the new one is
   attached into the DOM). As soon as this is done, the renderer
   calls 'on_attach_callback' on its children, including the
   FieldX2Many, which leads to a call to 'mounted' on the CP.
 - then, just before the nextAnimationFrame, Owl complete the
   rendering of the CP, and detects that it is now in the DOM (it
   wasn't at the beginning), so 'mounted' is called a second time,
   will cause the issue described above.

This commit fixes the issue by properly waiting for the CP to be
rendered in the FieldX2Many. However, this required on cascade
changes:
 - Form view renderings with a FieldX2Many are now *really* async
   (+- 16ms), meaning that the user can easily trigger concurrent
   renderings by, e.g. clicking quickly several times on 'Edit',
   'Save' or 'Discard'. Concurrent renderings are properly handled
   so to prevent this from happening, we disable the buttons and
   re-enable them when the rendering is done (like already done in
   [2])
 - in the FieldX2Many, '_updateControlPanel' was called at several
   placed, but we never waited for it. As this method was
   originally sync, its calls have probably been naively adapted,
   whereas their should have been deeply rethought (for instance,
   as it is async, and we need to wait for it, we don't want it
   to be called multiple times sequentially when something happens).
   This commit does that work, i.e. we clean the places where this
   function is called such that it is (hopefully) never called
   sequentially twice. To do so, we changed a bit the spec of the
   pager in multi page, and we also fixed a paging-related  bug.
   In a few words, here is what we did/do when adding a new row
   in the bottom of a full page:
     - before: tweak the count in the data to fool the pager and
       make it think that no new record has been added (so
       basically, let it display something wrong)
     - now: temporarily increase the pager limit so that the new
       record is displayed on the current pager, and the pager
       values are correct w.r.t. the displayed records.
    Some tests needed to be adapted accordingly.
 - By waiting for the ControlPanel when updating the FieldX2Many,
   a bunch of QUnit tests failed. Those tests have something in
   common: they spawn an X2Many (list or kanban theoretically,
   but always list in practice) containing a FieldBoolean (only
   field widget of /web converted in owl). When the FieldX2Many
   is updated, we update the renderer (i.e. re-renderer the
   FieldBoolean, so we have to wait for the nextAnimationFrame),
   and when this is done, we update the page (again, we have
   to wait for the nextAnimationFrame). So basically, we have
   to wait for two nextAnimationFrames to see the result in the
   DOM. For this, we added a new test util which basically does
   a nextTick ('owlCompatibilityNextTick'), and called it
   everywhere it was necessary. When everything will be written
   in Owl, we could get rid of this util and its calls.

[1] https://github.com/odoo/odoo/commit/fbf347498f1cc7b74ef373179b7bcae201715c24
[2] https://github.com/odoo/odoo/commit/39f08950d6e20460e3a20a5b9c33e4ddf66dce78

closes odoo/odoo#61593

Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>

An older commit (50bf8309) had refactor part of the basic field _applyX2ManyOperations.
During this refactor, the reference field was forgotten to be included
in a condition that made the field no longer do the quick create behavior.
The name_create function in the backend was no longer called.

Adds a test for the reference field checking the call to the name_create
function and fixes the problem.

Task id 2322048

closes odoo/odoo#59013

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

Task 2327599

It is used in the selector of a tour to know the type of a document.

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>

Generally, Users are not necessarily aware that they can quick create a most
records by simply typing in their name+enter in the many2xxx field input.
The exact purpose of this commit is to make sure the user discovers the quick
create feature of our many2xxx fields.

For that, when the input is empty, display 'Start typing to create a record...'
at the bottom of the dropdown when can_create is set and no_create_edit option
not set. So the user can easily understand that by typing and pressing enter
will create the new record.
Also "Search and Create" options in the dropdown only been shown to the user
when it type anything in the input box as the same case in the "Create" option.

Task : 2266557

Co-authored-by: Mohammed Shekha <msh@openerp.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>

A long time ago, commit [1] increased the limit of displayed badges
inside a many2many_tags widget, from 40 to 1000 (a large limit that
should never been reached with such a widget).

However, this solution was specific to the many2many_tags widget,
and didn't apply to its extensions (like the many2many_tags_email
widget). For instance, open the chatter full composer, add 40
partners in the recipients field and try to add one more: nothing
happens.

This commit sets the limit on the widget itself. That way,
extensions automatically have the same limit, and can override it
if needed.

[1] d4cf4374d1baa529bb651bb3cc32e9db140963a8

Task : 2091027

closes odoo/odoo#49488

X-original-commit: 02e41f1131b4ea3ad977cc241a3d447c37195f6e
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>

Use of the new control panel helpers to increase consistency and change the assertions
according to the new DOM/behaviour (e.g. components removed instead of turning invisible).

Part of task 2196029

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

By default, in readonly, unset field widgets (and their labels) are
not displayed. However, we would like the statusbar widget to be
always displayed (even when it is not set).

This commit introduces a new method 'isEmpty' on AbstractField, and
uses it (instead of isSet) to determine whether or not a field should
be hidden. By default, it uses isSet, so that it doesn't change
anything for the other fields, and we override it in statusbar to
always return false.

There was a need to make the distinction with isSet, as this one is
used to determine if a record can be saved (if the field is required,
and isSet returns false, it can't be).

task-2172272

closes odoo/odoo#43419

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