In the list controller, some code to determine the active domain to
export was causing a crash. It was easy to see: just select all records
in a list view, then click on 'Export' in the sidebar.
Note that the data_export code is still quite old, and did evolve
organically. It does not conform to our new design principles, in
particular, the way component should communicate. But this is a task for
another day.
With the new views, the special attribute password was no longer
supported. We simply reintroduce in this commit proper support to
display password fields with *.
Note: we may want to display passwords with a static number of *, but
this requires some thoughts on the usability of the change. We simply
reintroduce the previous behaviour here.
The 'Expand All' feature was tested, but in the test environment
RPCs are mocked, and everything is synchronous (by default). So
even if the tests passed, the feature actually didn't work because
of a deferred (the reload deferred) that wasn't waited for.
Keys 'pivot_measures', 'pivot_col_groupby' and 'pivot_row_groupby'
can be specified in the context and are meant to be used by pivot
views to determine the initial measures and groupbys. Before this
rev., the new implementation of the pivot view simply ignored them..
Before this rev., the _mockReadGroup function only supported
grouping on one field, and if called with an array of fields of
length > 1, the remaining fields were ignored.
Grouping on several fields is now supported, and some tests had
to be adapted.
Before this commit, the save method in the basic model did not properly
react when the rpc fails. In that case, the returned deferred stayed
indefinitely in the 'pending' state. This is a big problem, because the
basic controller put that deferred in a mutex. As a result, every
subsequent operations (including field changes!) were indefinitely delayed.
To reproduce the issue, you can find any form view where some python
business logic will cause a fail in some cases. For example, create a
new inventory adjustement, click on 'Start inventory', then add a line
in the x2many with the same product as another line. Saving that record
will fail, but then, the form view is broken: no interaction will work.
Before this commit, row decorations were only computed at the initial
rendering for a list view, then never recomputed. Most of the time, it
is not an issue, but list view can be edited, and in that case, it may
be a problem. With this commit, we just override the confirmChange
method to recompute the various decorations.
Note that in bonus, decorations now works in realtime, when editing a
list view (in saas-15, they simply did not work when editing a record)
Also, we now use the same evaluation context as everything else in the
web client: the eval context from the record, not some custom handmade
context like before.
Eval contexts are not easy... They should be different when sent to the
server and when evaluated in the web client. In this commit, we fix
some small issues:
- when evaluated on the web client, x2manys should be a list of ids,
when sent to the server, it should be a list of commands
- dates should be converted to string
- always add current_date in the evaluation context, as a magic key (it
was previously only available in row decoration context evaluations)
With this commit, we just slightly improve list benchmarks, to make them
go through a wider variery of code.
Since we aim to use these benchmarks to track changes in performance
through various versions, it is useful to have a good version in
saas-16.
Before doing an onchange in a x2many, the basic model tries to evaluate
if the line is valid or not. In that computation, we used the
field.required property instead of using the required modifier. This
commit had to move the modifier handling from the BasicRenderer to the
BasicModel, in order to use it in the _isX2ManyValid method.
This rev. fixes the next three bugs:
- the dataPoints representing each group didn't have the parentID
attribute set
- when quick creating a record, the res_ids and count attributes
of the group, and of the parent weren't correctly updated
- when quick creating a record, the environment (view_manager)
wasn't correctly updated
The combination of thoses bugs produced the following crash. Open
a grouped kanban view (e.g. project.task), quick create a record,
open that record in form view (note that the pager was wrong, it
indicated 0/x, where x number of records), delete the record ->
the form is supposed to load the next record, but it
crashed because it couldn't get its id (trying to read id null).
Previously, it used to reload its data when the user clicked
multiple times on save, even though there were only changed
fields during the first initial save, all the other queued
ones have no changes at all and, as such, should not trigger
additional reloads.
Previously, it was possible to click multiple times on stat
buttons while still waiting for the result of a previous button
click. This could end up with the web client in strange states
or, worse, lead to tracebacks. Because of this, we decided to
disable the buttons once one of them is clicked and restore
them afterwards.
By doing this, we encovered a place in the code where a failed
deferred would not be properly forwarded back to the caller,
which meant, in our case, that the buttons would not be
enabled back in case the action failed. This is now fixed.
Initial methods to fix this issue used to break the test below.
Because the label of the assertion this used to break was
contradictory with the value it was actually expecting, we
decided to fix it as well.
Previously, the buttons were not updated properly after discarding
from an editable list view. The user was stuck with "Discard" even
though there was nothing to discard anymore, and he could not create
a new record either since the "Create" button was invisible.
This was fixed by 3aad756. I originally did a different fix which
has since been rendered useless, but the tests I wrote are still
meaningful since they are testing a different case than the commit
which fixed the issue.
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...
In Kanban views, the 'Create' button must be muted (btn-default)
in grouped mode, if there is no column and if the column quick
create feature is enabled (as in this case, the first action
should be to create a column).
Before this rev, it was actually muted if there were no record, no
matter if there were columns or not.
This was because the 'count' attribute of dataPoints was used to
determine the number of columns, but this attribute represents
the number of records in the dataPoint (i.e. the sum of the number
of records in each groups).
This particular case was tested, but the test passed thanks to
another bug (we incremented the 'count' attribute in the kanban
model when creating a new group, whereas we shouldn't).
Before this commit, the o_field_invalid class was not removed once an
invalid field becomes valid, until the user saves the form view (which
will rerender the full view anyway)
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, the renderer interpreted the special tag, but ignored
modifiers and attributes.
Most nodes are rendered by the `_renderGenericElement` method, so this behaviour
is automatic. However, special tags need to do it explicitely.
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.
When grouping on a selection field, the read_group may return a
group for value false (containing records with the selection field
unset, typically). When this happened, there was a crash because
the BasicModel didn't handle that case (it assumed that the value
of the groups was always a valid key of the selection).
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)
... from a new record.
Steps to reproduce the issue:
- go to a multi-record view (e.g. list) of basically any model
- click on 'Create' -> it opens a form view in edit mode
- click on 'Discard' -> it goes back to the list
- click on an existing record -> it should open the selected
record in readonly.
However, it didn't display the data of the selected record, but
the default data of a new record (the result of a default_get).
This was because the changes weren't properly discarded when
reloading from a new record (it rather restored the record to its
initial state, i.e. to the result of the default_get).
Before this commit, when a test in the qunit test suite failed, the
error displayed by the runbot was not really interesting. It just said
that test_01_js failed. With this commit, each assertion error is now
logged as an error, which means that they are displayed in the short
error log by the runbot.
With this commit, we introduce a benchmarking infrastructure: a new
controller, accessible at the route /web/benchmarks which will render a
new template (web.benchmark_suite).
This template uses benchmark.js and qunit.js to display a list of
benchmarking informations. For example, the number of op/s for
instantiating and destroying a list view.
I hope that this is the start of the beginning of taking the habit to
check our JS code performance sometimes, and making sure we do not have
large regression without a good reason.
The form renderer defines inline style on the groups it renders to
set the width of their children according to the col and colspan
attributes specified in the view.
However, before this rev., this impacted inner list views (for
x2many fields), as their columns get an harcoded width as well,
whereas they shouldn't.
This was for example the case in the stock.location.route form
view, for the push rules and procurement rules o2m fields.
Editable grouped list views isn't a supported feature. Before this
rev., grouped lists weren't automatically set as non editable, so
it could cause crashes when the user clicked on rows of grouped
lists with editable="top" or "bottom".
This was for example the case in Timesheets > All timesheets ->
go to list view.
The 'data' attribute of exported datapoints (using 'get') must
contain a value for each field in the view, and the default value
is false when those fields are unset. The code manipulating those
datapoints supposes that this is the case and it makes it easier
and clean.
However, it wasn't the case for x2manys in new records for which
the default value contains CREATE commands with missing fields:
in that case, those missing fields weren't added in data.
This caused a crash in the Employee form view, in edit, if the user
clicked on 'Create and Edit' of the 'Working hours' field, because
some code in field_utils assumes that if the value of a date field
isn't false, it means that it is a moment instance (but in that
particular case it was undefined).
The buttons were not updated after column creation.
This was causing an issue in an empty kanban when you created a new column,
the 'Create' button was not highlighted.
After the record deletion, the parent should be updated to take the deletion
into account.
This was causing an issue in the Kanban view: after a column deletion, it appeared
again if you created a new one.
The attribute `widgets` has been renamed in rev https://github.com/odoo/odoo/commit/7ff8aa73e17b281b3e2bc4c7275d020eab0204e7#commitcomment-22116249
However, KanbanRenderer still uses a `widgets` attribute, not for the fields
widgets but for its columns (or records if ungrouped).
These widgets weren't correctly destroyed since then.
This was causing an issue when you were trying to quick create a record after a
column creation (that generates an update): the quick create was added in the
first old column (which was not in the DOM anymore) so you couldn't see it.
The kanban group expects to have local ids in its data and not the whole
datapoint.
This was causing a traceback when adding a new column after adding a record.
Géry Debongnie