The commit e07f27d has wrongly changed the fallback for one2many raw_value from
an empty array to `false`. This modification brokes a lot of templates where we
assume that the value is always an array.
This commit restores the previous behavior with the fallback on [].
With this commit, we try to improve the way navigation is done in the
list view. In particular, we want to make sure that pressing TAB on the
last editable cell move the cursor to the next line (and create a new
line if necessary).
Also, we add a few tests for keyboard navigation (it was almost not
tested before this commit, and while working on this commit, it was
broken at some point).
When we unselect a line in a one2many list, we ask for all fields to
commit their changes (because many fields are debounced, so we may not
know their current last value). This is good, except that it could
trigger an extra field change event, which may in turn trigger a second
onchange.
We solve this issue by improving the _setValue method and delegating the
comparison to a new _isSameValue method.
It is particularly relevant for field types such as integer, which are not
stored as a string.
When multiple clicking fast (and with the server not too fast), we could
end up with an error (eg. "Cannot read property 'controller' of null").
Something has been done previously to improve this when switching
between views in: fc8a4b5e. This commit do something similar to limit
multiple click on kanban records (doing it as in 26f91c429).
note: master equivalent of 8f1cc2fa (which is for 10.0 up to saas-15)
opw-705329
closes#16775
Suppose that there is a many2many (list) field in a form view,
and there is a many2many (e.g. many2many_tags) field inside the
list.
In edit mode, if the user adds a record in the relation, this
record and its relational data should be fetched.
Before this rev., the relational data wasn't fetched, so the
many2many_tags couldn't be displayed correctly.
Before this commit, it was possible to edit something in an editable
list view, then press the DOWN key, then enter some other values. With
the DOWN key, the focus is supposed to move to the line below, so we
save the current line, in the current state. This means that the edit
coming after are simply lost (well, just not saved nor displayed).
What this commit does is simply disable all control elements in that
situation. This prevents uncomfortable situations from occurring.
Before this commit, when a kanban view was grouped by a selection field, the
column were named with the raw value of the selection instead of the display
string.
Furthermore, fix the fact that when the column title was 0 or False,
'undefined' was displayed instead.
- Fix the toolbar behaviour since there is no more dataset in the widget.
- Improve the communication beetwen the controller and the toolbar.
- Move the code linked to the document upload in the right file.
- Adapt the tests to mock the search_read done by ´document´ addon
- Adapt the mock server to be able to give a custom toolbar action
Before this commit, if the user created a line (thanks to the create
button) then deleted it, the rows were in a broken state which made the
list edit the wrong line on line click (it opened the next one). This
was due to row indexes which are kept as data on rows: they were not
updated on row deletion. This commit simplifies the code by getting rid
of this indexes data and instead compute those when necessary.
In PostgreSQL, a field of type `integer` must be in the range
-2147483648 to +2147483647. If the user enters a lower or a larger
value, a traceback is thrown.
opw-740286
When a record is added in an x2many field with an onchange, the
onchange is only triggered once the new record is valid (i.e. when
all its required fields have a correct value).
However, there was an issue in the code checking the validity of
a record, as it iterated on all known fields of the model (instead
of those in the view), so if there were required fields that
weren't, the record was always invalid (as those fields obviously
never had a value), and thus the onchange was never done.
This wasn't a problem with embedded views as in this case, the
known fields are those in the view. But when the view isn't
embedded, all fields of the related model are known, even if only
some of them are in the view.
This was the case for example in the stock.picking form view, when
adding a line in the stock.move o2m: the onchange wasn't done and
thus, the schedule date wasn't correctly set.
Relational fields with attribute 'invisible' set to true are in
views because they are used in domains or contexts. In this case
their relational data is useless, only their ids matter. Before
this rev., their relational data was fetched anyway. More
precisely, it was the case for many2ones after a default_get, and
for x2manys with inline views, or without view (e.g. with widget
'many2many_tags').
The previous code used to create its own args array
for the search_read method, replacing the one that
was originally given to it.
This lead to silent errors since positional arguments
to this function were completely ignored in the case
of search_read.
I took this commit as an opportunity to improve a
bit on the current state of these rpc helpers.
Namely, the basic args/kwargs priority is the following (top-to-bottom):
- kwargs defined in the rpc call
- kwargs defined in the kwargs key of the params kwarg of the rpc call
- positional arguments are passed as is
For read_group and search_read methods, the priority is the following:
- kwargs defined in the rpc call
- kwargs defined in the params kwarg to the rpc call
- kwargs defined in the kwargs key of the params kwarg of the rpc call
- positional arguments are passed as is
For the /web/dataset/search_read controller, only the params kwarg is
supported, resulting in the following priority:
- kwargs defined in the rpc call
- kwargs defined in the params kwarg to the rpc call
- positional arguments are passed as is
If both a kwargs and a positional arg is given for the same parameter,
it will be sent as is to the server which will crash with a typical
"got multiple values for keyword argument" TypeError. However, in the
MockServer however, we give priority to kwargs over args in this case.
Please note that I also chose to remove unnecessary default values so
that the ones actually used are the ones from the server, not the ones
that were duplicating those in the rpc js file.
Widgets which manipulates their dom in _renderEdit were left out
from the previous implementation since this processing was done
only once when the widget is rendered the first time. If the
widget regenerates a new input upon reset for example, then it
would lack the idForLabel.
When enterprise is installed, the rendering of these widgets on
extra small screens is different, thus breaking these tests. We
need to force the test to run on normal screens.
Before this commit, when we moved from one line to the next, we did not
wait for the unselectRow to end. This means that if the read (from the
unselect row) completes after the default_get, the list renderer was not
in a coherent state (currentRow was set to null), which could (and did)
cause a crash.
This was found by pressing the TAB key a few times, and editing some
values.
Also, we slightly improved the logging in the mock server. Before this,
the responses from the mock server did not show from which route it came
from. But in this test, we specifically make sure that the rpcs
complete in a different order, so it was not really optimal.
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.
The FieldTimezoneMismatch was redone, but an error was done after the
last code review. With this commit, we fix the mistake (a function is
properly called) and improve the test to make sure we catch such a
regression later.
Trash icon does not take account of the option on the tree tag
Before this fix: The delete option on the tree tag is not taken
into account in the widget
Before this rev., there was a traceback when grouping a list view
by a, e.g., many2one field, and then by a selection field. It
crashed when formatting the title of the group, because the type
of the grouped field was incorrectly determined (it selected the
type of the inner grouping level, not the current one). For
instance, it tried to format a many2one like if it was a selection.
When switching between records, the active tab of the previous
record is made active on the new record.
However, before this rev., this was done without checking that
this tab is still visible on the new record (there may be an
invisible attrs that makes it invisible), so it happened that
the active tab was actually invisible.
This was for instance the case when switching between stock
pickings, as the first tab ('Operations') is sometimes hidden.
This commit actually fixes a few problems:
1. the _visitChildren method in the basic model was not following the
changes, only the data, so it was not correct (for example, the isDirty
method was wrong for relational data, when no other change was done)
2. new records could not be discarded, because they had no data in their
data key. What we do here is to add a savePoint, so it is safe to
restore them (it caused a crash)
3. the save method was not properly following children when it was
called with the option savePoint=true
4. when the user tried to discard a form view, in an action with only a
form view, it was redirected to the previous url (via the history_back
action), instead of simply discarding the current form view
When fetching record, `bin_size` needs to be passed in the context
to notify the server to send the `bin_size` and not the whole base64
of binary fields.
Moves back the mobile rendering part of the FieldStatus to
enterprise, alongside all other tweaks to improve the UX in mobile.
This part had been moved to community inadvertendly in the new
views branch.
We changed the do_action method recently: before, it was calling
recursively its parent, now it simply triggers up an event. We also
moved it to the 'services' mixin. However, we did not properly connect
the 'on_success' option: it is not an option for the view manager, but
for the abstract web client. As such, it should not be in the options
parameter, but it should simply be a key in the event payload.
This commit was found by solving the two following issues:
- open sale application, click on 'Inbox' icon to go to discuss,
Discuss is opened, but the navbar stays with sales application
- after installing module website_crm_partner_assign in kanban view for apps,
it does not reload...
Both of these were caused by the need to do something after a do_action,
and the deferred was not resolved at all.
The context sent when performing RPCs is a mix of several contexts
(user_context, action's context, context defined in a field's node
in an arch...).
In general, the action's context should not be mixed with the
field's context:
- for global RPCs (read a record, write a record, default_get...)
only the action's context should be given
- for RPCs triggered by fields (e.g. name_search in a m2o), only
the field's context should be sent.
The exception is for onchange RPCs, as in this case, both action
and field's contexts should be sent.
Before this rev, the action context was always sent, which might
produced tracebacks (e.g. go to Sales > My Pipeline > New > click
on Customer field > Create and Edit > boom).
Before this commit, the form dialog was open twice when you tried to
add a new record on a one2many if you were already in a modal.
The event wasn't stopped, so the first form dialog was correcly rendered
but the second one tried to load the same form view on a wrong model.
The basic model did not transfer field options to special data methods
from fields. This was mostly not an issue, except for the widgets that
actually need them, such as the status bar and the domain editor.
This was only visible when opening views with different view types,
but this is a problem in general. We should have a better mechanism to
help widgets fetching data, but for now, this is the best we can do.
This test executes the QUnit js test suite. Since the new views,
this suite keeps growing, which is good. The default timeout
for phantomjs tests is 60 seconds, which starts to be tight for
test_01_js when the runbot is overloaded.
So this commit increases the timeout of this test to 120 seconds.
Martin Geubelle