Before this commit, it was only possible to click on input to
change the value of the many2many_checkboxes widget.
For better consistency, we must allow to click on labels.
The motivation for this commit was to fix a wrong evaluation context for
x2m fields: it was using a list of res_id, which may contain virtual
ids.
For example, it could be seen in the form view for journal entries:
adding the first line (field line_ids) was fine, but clicking on 'Add an
item' a second time caused a crash. The reason was that the line_ids
was explicitely added to the context in the view, and the second time we
add a line, the web client sent a list looking like this [35,
'virtual_43'] to the server, in the nameget context.
The proper behaviour is to send a list of commands for those fields.
This means that we had to do some non trivial changes in the
getEvalContext method: we stop using the get method with raw: true. It
was nice to use the same method, but the eval context is actually
different that the values returned by the get method. That was the
motivation to introduce the 'noUnsetNumeric' flag, but now, we simply
create another method and let each method do its own work.
TLDR: eval contexts are hard...
It is not really easy to handle discard operations. We need to handle
the discard in editable lists, and in x2manys. This is not exactly the
same code, but most of this was done by moving the discard method from
the formcontroller to the basic controller.
With this commit, the user can now discard the changes for the current
record by pressing ESC. If the record is new, it will remove it, if
not, it will ask for confirmation before.
The issue that we fix in this commit is the following: open a form view
with a o2m with one required field, and the o2m is editable. When
adding a new line, it is invalid (since the field with required), but
when pressing ENTER, the editable list tries to navigate away, which
will discard the current line (in the unselectRow method), before
completing the move_to_next_line. So, at this point, the list editable
create a new (empty) record, and we are back to square one, but with a
visible flicker and no information on what happened.
To fix this issue, we simply check that the renderer can be saved when
moving to next line. If it is not (the line is invalid), then we simply
abort the move.
Notes:
* this behaviour worked fine in list view, because the canBeSaved check
is made by the saveRecord method in listController
* it looks like the protection should be put into unselectRow, but this is
not true (at least, in the current state): in some cases, calling
unselectRow with invalid state should result in discarding the current row
(in a new line in a o2m, when the record is not dirty, for example), and
the list editable renderer does not know if this is the case or not.
However, if the unselect action comes from a navigation event, then we want
to avoid discarding the current row.
When a many2one (in an editable list) with an onchange was edited, it
could happen that a modal window asking for confirmation of the creation
of a record was opened when it should not. Here is what actually could
happen:
* user focus a many2one
* user type something
* user press ENTER (keydown + keyup)
* user press ENTER again
* the onchange comes back
* modal window is open
Because of the onchange, the _reset method was called after the
_onInputKeyup method. So, the m2o_value was not equal to the
$input.val() and the 'floating' flag was set to true (after the first ENTER).
The second ENTER caused a unselectRow in the editable list, so the input
was focusouted, and the modal is set. This is basically caused by the
asynchronous behaviour of the onchange.
We simply fix the problem by setting the floating flag back to false in
the keydown method.
When a many2one (in an editable list) with an onchange was edited, it
could happen that a modal window asking for confirmation of the creation
of a record was opened when it should not. Here is what actually could
happen:
* user focus a many2one
* user type something
* user press ENTER (keydown + keyup)
* the onchange comes back
* user press ENTER again
* modal window is open
Because of the onchange, the _reset method was called after the
_onInputKeyup method. So, the m2o_value was not equal to the $input.val() and
the 'floating' flag was set to true, which means that the _onInputFocusout
method (called indirectly by the listeditablerenderer when unselecting the row)
was forced to open a confirm dialog.
We simply fix the problem by setting the floating flag back to false in the
reset method.
Before this commit, when the user write some text in a many2one, then
press ENTER, the key event will trigger a navigation move, which will
validate the field, and move the focus to the next line. The same issue
happens when pressing TAB.
With this commit, we simply stop the propagation, and preventdefault the
event that cause the selection.
Before this commit, when editing a many2one (with an onchange) by
clicking on the small form button on the right, then changing something,
then saving the modal dialog, no onchange was triggered, because,
technically, the value of the many2one was not changed, only the values
from the record pointed by the many2one were.
The same remarks applies to many2manys.
To see this issue in odoo, you can open a product (technically, a
product.template) from the 'Catalog' menu in sales, then edit it, then
click on the small form view icon next to Internal Category. This is a
many2one (categ_id) with an onchange. In the form view dialog, change
something, for example costing method, then save. The res_id of the
internal category was not changed, but an onchange should still be
triggered.
When a SelectCreateDialog was opened with a given domain, this
domain was completely lost if the user wrote a new domain (or
groupby) in the searchview, whereas they should be concatenated.
Suppose that there is a one2many list in a form view containing
a field F, displayed with no widget, and that F is also displayed
in the one2many form view (opened when clicking on a record of the
list), but that in this form view, F is displayed with a widget
requiring specialData (additional data to fetch alongside the
record), e.g. widget="domain".
Before this rev., it crashed when this happened because those
specialData weren't loaded when opening the related record.
Credit goes to @pga-odoo for reporting the bug and reproducing it
in a test.
DebounceFields debounce the function that notify field changes to
their environment (using _.debounce). It may happen that this
function is called once the field widget is destroyed (e.g.
type something in a char field and quickly click on Save, the
function is called directly by _commitChanges, but the debounced
call is still pending). It may be a problem if the subsequent
code does something like this.getSession().some_key, as if the
widget is destroyed, it has no parent that can provide it the
session, and thus it crashes.
Also rename attribute _debouncedStarted into _isDirty as it makes
much more sense.
Passing multiple ids wasn't correctly handled as the argument `record_id`
was wrapped in a list of list, which is not hashable.
The wrapping is now handled by the caller.
Before this commit, when creating a new record, we only looked at the
main fields to determine if a call to onchange was needed. This was not
enough, since sub fields (fields in a one2many for example) can have an
onchange.
This was an issue only for new records with onchanges in sub fields, but
no onchange on main fields. For example, the merge contact wizard.
To solve this issue, we had to propagate the current view type from the
field to the basic model, because otherwise, the main viewtype was used
to compute the onchangeSpec, and that is not always correct.
Before this rev., the FieldRadio didn't work on selection fields
with keys like "0", "1"... i.e. strings that can be converted to
numerical values. This was due to an automatic conversion of those
keys to their numerical value by JQuery, so when the user changed
the value, an unknow key was sent to the server (e.g. 1 instead of
"1"), causing a crash.
This rev. changes the logic a bit so that the keys are no more
written in the DOM, but their index in the selection are.
The server doesn't make a distinction between an unset selection
field, and a value 0 (integer). So when 0 is a valid key for the
field, the server returns false as value if the field is unset, or
if its value is 0, which is not really convenient.
As a consequence, when the value is 0, it appears as unset in the
interface. To circumvent this, we automatically converts false
value of selection fields to 0, if 0 is a key of the selection.
Many2many default value can be a list of ids, and in that case, we did
not properly load data.
It could be seen by selecting a few contacts (in list view), then
opening the 'Merge contact' wizard in the sidebar (action menu). Before
this commit, the wizard did show a list with some empty rows (for the
field partner_ids).
In the xml definition of views, a 'currency_field' can be specified
in the node options:
<field name="amount" widget='monetary'
options="{'currency_field': 'currency_id'}"/>
It indicates which field the monetary widget has to use to
determine the currency to display.
Before this rev., the widget didn't look for the 'currency_field'
in the options, but directly in the node attrs, so this simply
didn't work. This was for example the case on the crm.lead kanban
and form views.
This rev. removes some html injections issues:
- in char and text field widgets
- in phone field widget in mobile
- in list views (when no widget is instantiated)
Previously, the string attribute of the field node was ignored
in the title of the form dialog and it always displayed the
string value of the python field definition instead, which is
a default value instead.
Additionally, I took this opportunity to add tests for other
similar dialog titles which actually worked already with the
string attribute of the field node but were not tested yet.
Previously, when a checkbox was re-rendered, it was losing focus
since it was removed and re-created. Now, if the checkbox itself
is the origin point of the re-rendering, we give the focus to the
newly re-rendered checkbox, resulting in a seamless experience
just as if the checkbox was never removed and re-rendered.
Before this commit, it was not possible to see the difference between an
unset float field (with a 'false' value) and a set field (for ex, with
value 0)
This was due to the fact that the formatFloat/formatMonetary functions
format false values as the number 0, unlike many other formatting
functions.
... in x2many editable list views.
Field widgets can detect that they are at the origin of a
field_changed event, so that they don't re-render themselves when
they are being edited.
This didn't work for fields inside x2many list views. This wasn't
a big problem for most of the fields, because the cursor position
was automatically reset after a re-rendering, but it wasn't
working for monetary fields that empty their $el before each
re-rendering.
This rev. fixes the issue by making the field widgets inside
x2many list able to detect that they are the origin of a change,
and thus removes the now useless code that restore the cursor
position.
The 'get' method in the basic model is called very often (too often, but
that is another issue). For a large list with many columns, it can be
quickly be called more than 10k times.
In that function, we had to protect our integrity by performing a deep
clone with $.extend, so noone else can be allowed to change something in
our internal structure. This is good in theory, but not so good in
practice, as $.extend is a really expensive operation.
Also, we try to have the smallest external API by deleting useless keys.
But instead of keeping a blacklist of private keys, it is simpler to
have a whitelist of public keys.
So, what we do is to explicitely construct the object returned by key,
since we know the types of every values involved. This is more
explicit, and at the same time, much faster.
Also, we propagate the options for elements of type list. This is why I
had to change the isFieldSet method.
In a benchmark I just ran, loading and rendering a large list (200 rows,
7 columns) went from about 2.7s to 0.7s.
We still do way too much work, but at least it is much faster...
This rev. fixes 2 issues about many2many fields displayed with
an editable list view, occuring when the user edited some values
in the list.
First, the many2many field was re-rendered each time one of its
sub-widgets triggered a 'field_changed' event, and thus the row
the user was editing was no more in edition and the focused field
was no more focused. This was quite annoying.
Second, when the user saved changes made in the editable list view,
only a command 6 (REPLACE_ALL) was sent, so updates of subrecords
were never saved.
Before this rev., if you opened a form view with, e.g. a float
field, that is unset, and then click on edit, then save, it
actually saved the new value for the float field (being 0),
whereas it shouldn't do any RPC as nothing changed.
This is because the former code couldn't detect if the value "0"
in the input is there because the field is still unset or if the
user simply set it to 0.
Before this rev., the function that parses monetary fields (i.e.
the one that converts the string value of the input into a
numerical value) totally ignored the sign of the value.
Actually, parsing a monetary field is exactly the same as parsing
a float field, so we simply use the same function.
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 checked, for each required field, that its value
wasn't falsy (!value). This is incorrect for several type of
fields:
- numerical: a value of 0 is correct
- boolean: should be always considered as correct
- x2m: their value is a dataPoint, so it is never falsy, what
should be check is the number of records inside the dataPoint.
This was an issue for example in the sale.order form view, as the
onchange wasn't triggered when an order line was added (with a set
product), so the total amount wasn't updated correctly.
Since the new views merge, a lot of design elements were broken. This
was particularly impacting the fields in the editable list view; indeed
the editable list view is not using an inline form view anymore so the
fields in the list were not properly styled as the LESS was still
defined assuming the form view environment (for example the invalid
fields were red for o2m fields in form view but not in editable list
view even though they got the right CSS class).
This commit refactor the LESS following these rules:
- No more division of non-layout and layout rules. Dividing LESS rules
in x_layout.less and x.less was a mistake. Many rules can be
considered to be layout and not layout at the same time, developers
always have to switch from one file part to the other, many CSS
selectors (and rules!) are duplicated for nothing, ...
- Field style is extracted from x_view.less and put in the new
fields.less file. As before, the fields_extra.less will contain the
rules specific to community so that the enterprise repo can override
those by replacing the whole file.
- Many classes have been renamed so that o_form_x_y becomes o_x_y as
many classes can now be applied outside of form view. These classes
should not be used in templates anyway.
The commit also changes the DOM of fields so that it is more minimalist
(no useless parent div, etc).
Input elements are not automatically styled anymore, they have to get
the o_input class explicitely. This allows to fix lots of small style
bugs of previous versions (required monetary field had not the proper
style, readonly m2m tags appeared as editable, ...). This also improves
the LESS code.
The editable list view should also completely stop flickering on chrome
and firefox.
The commit also removes the orange outline on list view dirty cells.
The commit also removes deprecated static xml, LESS and other code.
Notice there are still styles to restore/fix and LESS to improve.
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.
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.
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.
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.
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
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.
hr_holiday was the only module that used a widget=toggle_boolean on a
button in a list view. That behaviour was implemented as a column
widget in the previous list view, and was not reimplemented in the new
views. The feature is useful, but this was not done properly: it is
better to use a widget on a field (that was the intent) instead of doing
a weird hack like it was done.
With this commit, we update hr_holidays to use the ToggleBoolean widget,
which is supposed to work on every views.
Also, we fix the toggleboolean widget (it was not properly rendering
tooltips, and changes were not saved in readonly list view).
Note that it as the side effect of being better from the point of rpcs:
before, the list view had to reload itself. Also, another advantage is
that models do not need to implement custom methods (such as
toggle_payslip_status) just to toggle a boolean...
When evaluating a context, we need to use the server format for dates,
because the context will ultimately be sent do the server. Also, moment
objects are not known by pyeval, so they simply cause a crash (for
example, see bank statements form view, edit it, click on 'add an item')
With this commit, we make sure that the evaluation context is correct,
with respect to dates (we use the toJSON method, because that is the way
we get the server compatible date)
In general, with the new views, we execute immediately and recursively
all onchanges, even from a x2many in a form view. It allows for nice
interactivity, for example, recomputing immediately a total or a tax in
a sale order when an order line changed.
However, we are used to treat x2manys in a slightly weird way: for
example, if you add a line in a one2many, then click elsewhere, most of
the time, it is validated. But if the line is 'incomplete' (I mean, if
a required field is not set), the line will not be validated, but be
automatically discarded. If it was dirty, a confirm dialog will open.
So, to keep in line with that semantic, we have decided that onchange
will just not be done until the line is 'valid'. This will avoid
trouble when someone add a line, it triggers some onchange which changes
some values in the form, then click somewhere else, the line is
discarded, but the changed values persist. Most of the time, it
probably won't be a problem, because another onchange will be triggered,
but it is some useless work anyway.
Adrien Dieudonne