In many2many lists, the remove record from the widget is a trash bin.
It is confusing, as people feel they are deleting it when they are
only unlinking it.
So in many2many, we propose to change the trash icon by a 'X'.
This icon appears in many2many relations and in many2many widgets:
even though hr.expense.sheet defines the expense lines as a one2many,
it uses a many2many widget, so we use a 'X' instead of the trash bin.
To avoid ambiguity, we decided to rename 'delete' to 'remove'.
[FIX] web: Fix column_invisible issue
This commit fixes an issue with the column_invisible attribute.
When we choose product variant for BOM for any particular product,
at that time from the BOM Lines column "Apply on Variants" is hidden,
but when we unset product variant from BOM Form,
at that time the column 'Variants" set to visible. but in this case, it is set to hidden always.
PR 21693, OPW 779555
[FIX] web: Fix column_invisible issue
This commit fixes an issue with the column_invisible attribute.
When we choose product variant for BOM for any particular product,
at that time from the BOM Lines column "Apply on Variants" is hidden,
but when we unset product variant from BOM Form,
at that time the column 'Variants" set to visible. but in this case, it is set to hidden always.
PR 21693, OPW 779555
If a row is being edited, this row will be refocused when performing changes
(i.e. resequencing records). It can cause an issue if an onchange modifies the
record being focused.
To avoid this issue, the row is unselected before resequencing records. The row
isn't selected anymore but this behaviour wasn't expected anyway.
Resequencing records with the same sequence wasn't correctly working in the
editable list because we only care about the range between the swapped ids. In
some cases, this isn't good enough.
For example, if we have the records 1,2,3 with sequence field = 10,10,10, then,
swapping records 1 and 2 should lead to resequencing 3 with the sequence values
11,10,12 (to guarantee that the third item is after the previous 2).
Resequence now checks if the list increases or decreases without interruption
to create the subset that must be changed ; otherwise the whole list is changed.
Before this commit, the way mode was handled was not optimal. The end
result was correct (the widget were properly created/displayed in
edit/readonly as required), but useless work was done. In particular,
if we have list/x2manys with widgets and modifiers, it could happen that
widgets were created in edit mode, then destroyed and recreated in
readonly mode.
This could happen in some important views, for example, any view with a
field many2many_tags with a readonly modifiers (pretty much all views
handling taxes)
In this commit, we add a 'editable' attribute to list renderer. This is
necessary, because the list renderer is not actually editable when it is
in a x2many in a form view which is in readonly mode. Also, we need to
manage the distinction between the fact that a list view is editable,
and the fact that some widgets are created in edit and other in readonly
mode, depending on modifiers, and on which line is being edited.
We also add a benchmark (courtesy of CHM) to be able to measure the
performance impact of edit/readonly/onchange in a larger form view.
Before this commit, running this form benchmark on my machine gave a
number of 0.4 op/sec, and after, it increases to 1.26 op/sec, so a
pretty large improvement.
This rev. introduces two helper functions for the tests: patch
and unpatch. Those function allow patching an Odoo Widget (e.g.
AbstractField), and unpatch it at the end of the test with the
guarantee that the Widget's prototype is exactly the same as it
was before the test.
This was necessary because the way it was done before was a little
bit too naive, and could lead to unexpected behavior. Indeed, doing
var someFunction = AbstractField.prototype.someFunction;
// test content
AbstractField.prototype.someFunction = someFunction;
is correct if someFunction is actually define (or overriden) in
AbstractField, as in that case, it really exists on its prototype.
Otherwise, it isn't correct if it is not directly defined on the
prototype before the test, as it will be after..
This rev. introduces two helper functions for the tests: patch
and unpatch. Those function allow patching an Odoo Widget (e.g.
AbstractField), and unpatch it at the end of the test with the
guarantee that the Widget's prototype is exactly the same as it
was before the test.
This was necessary because the way it was done before was a little
bit too naive, and could lead to unexpected behavior. Indeed, doing
var someFunction = AbstractField.prototype.someFunction;
// test content
AbstractField.prototype.someFunction = someFunction;
is correct if someFunction is actually define (or overriden) in
AbstractField, as in that case, it really exists on its prototype.
Otherwise, it isn't correct if it is not directly defined on the
prototype before the test, as it will be after..
The 'main_flow_tour' noticed an error that we
had already corrected for the input fields.
See here: @a71f2237
In fact the same error can occur in the many2one fields
for the exact same reason.
It's why the 'main_flow_tour' crashed at the following step:
".ui-menu-item > a:contains('the_flow.customer')"
Before this commit M2Mtags widget did not translate.
This was because no context was given to the rpc that fetched the fields
Hence, the lang was not passed.
After this commit, M2Mtags translate well
OPW 784396
When fetching batched namegets (typically after a default_get), we need
to evaluate the context that we send to the server. This may be
important for models with a custom name_get method. (note: overriding
namegets should be avoided if possible)
With the new views refactoring, this was not done properly and the
'view' context was sent instead. This is not really critical, the proof
is that it took a few months before getting some complaints, but this is
definitely a bug.
To reproduce, simply add a context attribute to a m2o field in a form
view, with a non empty value in a default get, and look at the context
sent to the server.
Consider the following situation: a form view with a one2many which
contains sub x2many fields (for example a m2m_tags). Suppose that the
one2many has more than 40 records. Before this commit, trying to delete
one of these records caused a crash.
The reason is that when we delete a record, we need to reload the
missing records in the one2many field. We actually do that with a
_readUngroupedList. However, the _readUngroupedList method did not
process x2many fields, so the information stored in the datapoints was
'raw', and the rest of the web client expected it to be a datapoint.
To reproduce the issue in the testing environment, i had to use
onchanges and a readonly attrs, to reach a situation where a crash could
occur. This shows that, while the issue is critical, it was not totally
trivial to be impacted by it.
Before this commit, the 'limit' attribtue worked properly for list views
(but was not documented), and was ignored for inline tree views. There
was no good reason for that limitation, so we fix this issue.
New feature:
- New Transparent tag visual (grey border & text, white bg),
- By default, newly created kanban tags are transparent,
- Tag's colorpicker has now a 'Hide in Kanban' checkbox,
to select the transparent color.
Toggling off 'Hide in Kanban' sets the color of the tag as follow:
- Previous color, if 'Hide in Kanban' was toggled on on the
same formview session.
- Color 1 (dark orange), otherwise.
Consider this: a form view with a one2many list view. In the one2many
list view, there is a many2one field. When opening the manyone in a
modal form view, there is a many2many field. In that situation,
clicking on 'Add a new record' on the many2many field had the
unfortunate effect of interfering with the one2many field in the main
form view, which caused a crash or the modal form view to close
unexpectedly.
The issue is that an event was simply not properly stopped at the proper
location. This is usually not a big deal, but, as described above, it can be
a problem in some cases.
Here is a situation where we had a problem:
- a form view with a one2many field, which has no inline views
- the (non inline) list view has a field A, and is not editable
- the (non inline) sub form view has fields A and B, with an onchange on
B which modifies A
In that case, the user could do this:
- go to edit mode
- click on 'add' a new one2many line
- change the value of B in the form view, this changes the value of A
- click on save to close the modal form view
- click on the new o2m record to reopen the modal form view
- rechange B
=> the onchange does not work
The explanation is that when we reopen the modal, we update the known fields
information, but we had to perform a fieldviewget to fetch the list
view, so we have a full knowledge of the fields. However, the code did
not update the fields info (because it uses _.default), which means that
the onchange information contained in the form view is lost.
Note: the test system had to be adapted to more closely simulate what
actually happens. In particular, the onchange flag is no longer added
by the mock server, since it should be done by the data manager, like
'real' code. This change broke the basic model tests, which had to be
modified accordingly, by setting manually the onchange flag.
Here is a scenario that could cause an issue:
- open a form view with a many2one
- click on edit button
- click on small external button for many2one. this opens a modal form
view
- click on save in the modal (without changing anything)
- click on save in the main record
- exit form view. this opens a discard dialog
There were two issues here:
- saving the modal dialog automatically marks the many2one field as changed.
This was necessary to force reloading the data, because editing a sub value
in the modal form view could have changed the display_name of the manyone
field. However, this is not necessary when no change was done.
- when saving a record, the _isDirty flag was reset to false only if an
actual rpc was done. However, it may happen that the flag is set to
dirty (for example, when modifying a value inside a many2one), but the
main record has no changed fields.
In this commit, we also remove the on_save handler in the
formviewdialog. This is a small refactoring in a stable version, but no code
currently use it, and I believe that it will make the code much easier
to maintain (the previous code was really awkward), so I think that the
tradeoff is acceptable.
After entering a value in a many2one, if one clicks somewhere else, a popup
is opened to suggest the user to create (or not) a new record with the entered
value.
Before this rev, closing this popup resulted in an unclear situation where the
input was still set with the entered value but the new record hadn't been created.
This commit fixes this by clearing the input value if the record is not created.
See task#36055
Before this commit, many2one fields were not (fully) usable in a list view: if
the user wrote some text, then when a dropdown with various choices
opened, pressed the 'down' key (to select a choice), the down keypress
caused a navigation move to the next line, which cancelled the
selection.
In this commit, we make the assumption that if the many2one dropdown is
opened, then navigation moves are not what the user wants.
When an onchange fails (for example, because the onchange python code
raised a ValidationError, it is convenient to revert the form view to a
valid state, which is the previous state.
To do that, we keep in the _applyChange function the initial state, and
restore it in the case the onchange fails.
Suppose that we have a form view with a one2many field o2m_1,
displayed as a list. The model of o2m_1 contains a one2many field
o2m_2 which isn't displayed in the list view, but which is in the
form view. If an onchange sets the value of o2m_1, e.g. with a
command 0 to create a new record, and that the value of o2m_2 for
this new record is set (e.g. with a command 0 as well), it crashed.
A traceback was raised when opening a new record for a model with a
one2many displayed inside a one2many (e.g. simply displaying the
number of records in the relation), and with an onchange setting a
default value to the inner one2many (for example, linking it to
existing records).
As the inner o2m has no subviews, it has no fieldsInfo, and the
code assumed that fieldsInfo was always set.
This was for example reproducible from v11 as follows:
- create a product (with MTO/Buy and call for tender (need
purchase agreement module))
- create an SO with this product and confirm it
- go to purchase order form view and add a move_dest_ids field in
the tree definition of field order_line
- go to menu purchase agreement and choose the PA generated by
your SO
- add a vendor, confirm the PA and click on 'New Quotation'.
The ORM doesn't automatically link subrecords when it receives an
update command for a one2many. However, it may be necessary when
the default_get returns existing records for a one2many field. It
only worked before this rev. for the hr_expense model because of an
hack from 2016 (to reproduce: go to Expenses, check some expenses
from the list view, in Actions, click on 'Submit to Manager', the
new hr_expense_sheet contains the checked expenses (one2many), and
the webclient only sent an update command by linked subrecord).
This rev. fixes the problem properly: when the default_get returns
existing subrecords for a one2many field, a link_to command (4) is
generated alongside the update (1) command.
It could happen in some cases that a rpc coming from a view was not made
with the context of the view (and from the action). For example,
- enable "Lots & Serial Numbers" in the inventory settings
- create a stockable product tracked by lot
- go to the inventory dashboard, on the "receipts" card click on the
three dots and then on "planned transfer"
this link forces the context key "planned_transfer" in the action
https://github.com/odoo/odoo/blob/11.0/addons/stock/views/stock_picking_views.xml#L725
- now add a stock move to move some quantity of the product you just
created
- see that no button appears on the one2many list
- save
- see that a button appears on the one2many list
This is an issue because the read on the o2m at the end is made with the
wrong context. The reason is that when we fetch x2m, we create a new
datapoint of type 'list' which did not reuse the context of its parent.
issue: When reorder each line trigger an onchange on the line (if they are an
onchange linked to the field) and one onchange per line on the parent.
Adding an option doNotNotifyChange to avoid the trigger on the parent.
With the new views, we mainly focused on making them work. But we also
need to be able to handle unusual cases, such as some RPC failing. An
example of such a problem was the following:
- a form view with a one2many with an onchange
- edit mode, change a field in the one2many, click elsewhere
- the onchange triggers, calls the server
- it may happen that the server fails with a ValidationError
- the onchange deferred fails, the line in the one2many is restored to
the value known by the list renderer, which is the previous value (but
the new value was applied to the model)
- we now have a 'corrupted' state: clicking on save will send the
invalid value, even though the UI displays the previous one.
We solve this problem in this commit by making sure that the onchange
deferred returned by the _performOnchange always succeed (or stays
pending). If the rpc fails, the deferred will succeed with an empty
dictionary. This means that the list renderer will be updated with the
value from the model.
Note that it may not be intuitive that a failure in the onchange is not
seen as an error from the perspective of the _performOnChange, but I
think that it still makes sense:
- the validation/network errors are not really a concern of the UI. The
UI just display the values entered by the user.
- if an onchange fails (for example, because of a coding error), we do
not really want to prevent the user from working.
Also, when the onchange is performed, the initial change was already
applied to the local data. Rollbacking them would be a more difficult
task.
Note that we also improve the mock server in this commit, to allow
mocking failures.
We had an interesting bug with the field many2many_checkbox: in some
cases, it could cause a crash, because it could not find an element in the
localdata.
To reproduce this, start with a non empty field many2many checkbox, then
uncheck them twice.
The reason is that the datapoint of type 'list' that represents the
current value is actually modified, and the replace_with operation
assumed that it could find the localID by looking into its data. I have
the feeling that a more complete fix is to make sure that the datapoint
is not modified (in its 'data' key), but is modified in its '_changes'
key. However, this would probably be a bigger change.
When we generate commands for many2many, it could happen that the id was
in the list of changed fields (when we are in a new records, with a non
empty initial onchange). When this happens, the server is not happy.
To reproduce this, open the uninstall wizard of a module in the 'App'
application. This creates a new record with a non-empty many2many
field. Then click on 'Show technical modules', this will trigger an
onchange which should not send the id field.
When creating a new record with a non empty default value for a one2many
field, we did send the command 0 (for each one2many line) instead of the
command 1 (update). This was a pretty big problem, because then the
server would try to create a line with possibly incomplete data.
For example, it was not possible to create expense sheets: go to expense
menu, select one expense in the list view, click on the action menu
'submit to manager', this opens a form view with a one2many with the
selected expense, then save. Before this commit, this would lead to a
server error.
This commits fixes a traceback that appears when ticking a checkbox in
an x2many which triggers an onchange. The root cause of the issue is
twofold:
- confirmUpdate requires currentFieldIndex to be defined, but might be
needed when setting currentFieldIndex;
- confirmUpdate attempts to restore the selection range even if we are
not dealing with a char field (e.g. checkbox).
We solve the issue by ensuring that _selectCell gives a temporary value
to currentFieldIndex. This value is chosen so that confirmUpdate calls
_selectCell with the right parameters. Moreover, we only restore the
selection range when the range is defined.
Before this commit, the widget many2many_tags only loaded the first 40
records. This was difficult to see, because there were not so many views
with a lot of tags.
Christophe Simonis