[REF] web: restore editable list views behaviors

Since the new views, the editable list view lost some behaviors. These
behaviors were indeed implemented in the form controller/renderer but
as the new editable list view does not use an inline form view, these
behaviors had to be implemented in the basic controller/renderer.
For this to work, the list editable renderer had to be changed as it
was doing work that should be done by the controller.

The problem is even more complex because the x2m fields are using a
list renderer but not a list controller. So moving code from the
renderer to the controller obviously broke the x2m fields. Right now,
the problem is solved by catching renderer events and forwarding new
ones to the form controller (which handles the x2m specifically).

The initial goal of this commit was to share the validation of records
on save. Indeed, the fields were marked as invalid in the form view but
not in the list view. Also, before the new views, the editable list
view had different behaviors if they were used for a x2m field or not.
As these behaviors are making sense, this commit tries to restore them.

Basically, what we want is:
- When a record is saved (form view save or list view line leaving),
the invalid fields are marked (in red), the names of the related fields
are notified to the user and the record is not left.
- When a record is discarded (form view discard or list view discard),
the user is asked to confirm if the record is dirty before making the
record readonly.
- When a record is discarded, if the record is a new one, then the
record should be abandoned (removed as if never existed). In the form
view this induces to go back in the history and in the list view, to
remove a row.
- For x2m fields, the notification of invalid fields is not triggered
but the user is instead asked if he wants to discard the changes made
to the row (indeed, this replaces the list "Discard" button, as non
existent for x2m lists).
- ...

Saving, discarding, marking the fields as invalid and other behaviors
are thus now shared behavior of basic views.

The management of the dirty flag has also been moved to the model
as it was handle by the controller for the form view but by the
renderer for the list view. Now this flag is directly managed in the
basic model (the model can have changes thanks to the `_changes`
property but not be dirty (this is the case for creations)).
This change however created a problem. The view manager is currently
keeping asking if there are changes to discard at each action which
might lead to leave a dirty record (appswitcher / url change / ...).
It however did not discard anything as leaving if the user is ok with
it will lead to an implicit discard. However, as the view manager might
ask for this discard multiple times by second, the controller was
marking the record as not dirty the first time but without discarding
the changes. This is more complex to do now, as the dirty state is
part of the model and that the renderer should match the model data.
To solve this problem, the view manager now actually discard changes
explicitely when asked to. Even though this had been optimized to not
cause any rerender in some cases where it is not needed, this could
cause some performance decreasing. However, this makes some cases more
logical (opening the app switcher on a dirty form view then going back
to the form view by hitting the "go back" button left the form view
untouched although the user asked to discard it). This solution will
be improved with the view manager refactoring.

This commit is also making use of the `commitChanges` system which had
been implemented for HTML fields. Indeed, these fields cannot know
about all of their changes, so when hitting the save button, we asked
those fields to commit their value. Using this system is a great way
to make the `isValid` method of x2m fields synchronous. Indeed, before
this commit, the method was sometimes asking the user if he wants to
discard an invalid line before save. That case can be handled by the
x2m `commitChanges` method: we consider that saving the lines of x2m is
an operation that has to be done before considering the save, so we ask
all the x2m fields to do so at that time. Also, the system was broken
since a recent commit: we indeed protected the changes - save order
with a mutex but unfortunately, the `commitChanges` method was part of
the save and the changes it triggered were not able to be considered
because of this mutex. This had not been detected by tests as there is
not current way to test html fields.

1 files changed, 0 insertions, 29 deletions

diff --git a/addons/web/static/src/js/views/field_manager_mixin.js b/addons/web/static/src/js/views/field_manager_mixin.js
index 287bd800576..ceedbb2df6e 100644
--- a/addons/web/static/src/js/views/field_manager_mixin.js
+++ b/addons/web/static/src/js/views/field_manager_mixin.js
@@ -12,8 +12,6 @@ var BasicModel = require('web.BasicModel');
 
 var FieldManagerMixin = {
     custom_events: {
-        discard_changes: '_onDiscardChanges',
-        discard_line: '_onDiscardLine',
         field_changed: '_onFieldChanged',
         load: '_onLoad',
     },
@@ -88,33 +86,6 @@ var FieldManagerMixin = {
     //--------------------------------------------------------------------------
 
     /**
-     * Controlled elements might want to ask for a discard of the changes made
-     * to a whole record (see editable list view). In that case, this handler
-     * is called and call the appropriate @see BasicModel.discardChanges
-     * function. The result is then notified thanks to a call to
-     * @see _confirmChange.
-     *
-     * @private
-     * @param {OdooEvent} ev
-     */
-    _onDiscardChanges: function (ev) {
-        this.model.discardChanges(ev.data.id);
-        this._confirmChange(ev.data.id, [], ev); // TODO get real list of changes ?
-    },
-    /**
-     * In some case, we may need to remove an element from a list, without going
-     * through the notifyChanges machinery.  The motivation for this is when the
-     * user click on 'Add an item' in a field one2many with a required field,
-     * then clicks somewhere else.  The new line need to be discarded, but we
-     * don't want to trigger a real notifyChanges (no need for that, and also,
-     * we don't want to rerender the UI).
-     *
-     * @param {OdooEvent} event
-     */
-    _onDiscardLine: function (event) {
-        this.model.removeLine(event.data.id);
-    },
-    /**
      * This is the main job of the FMM: deciding what to do when a controlled
      * field changes.  Most of the time, it notifies the model that a change
      * just occurred, then confirm the change.