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.
Before this commit, an issue occured when you tried to
create a new record in a editable grouped list view.
A new line was created with an undefined group.
Editable grouped list views are not supported.
So now, we have to switch on the form view when
you click on create. This behavior is already implemented
when you open an existing record.
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.
An error occurred if the domain or context applied on a view
opened in a dialog needed to be evaluated (e.g. if they contained
something like [['some_field', '=', uid]]). For instance, create
a custom filter with such a domain for the Contact model, then go
to Contact, create a new one, and on the parent_id many2one, click
on search more. Before this rev, no eval context was given so the
domains and contexts couldn't be evaluated, and it crashed.
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.
A recent fix in web changed the field FieldImage to make sure it also
loads a __last_update field. This is fine, except that a test in
enterprise (web_clearbit_tests) was using a field image, and failed
because it could not find the __last_update field in the demo data.
With this commit, we make sure that the mock server is always aware of
the __last_update field.
Calendar tests did not go into US for a timezone problem, making it more difficult to correct errors.
To do: pass all the tests js in US (with simplification for the calculations of the times)
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.
Before this commit, buttons in form view with the confirm attributes had
a peculiar behaviour:
- < saas-16: they saved the record as soon as you clicked on them, so
the warning was basically ignored
- in saas-16+ (the new views): the button did not save the record before
calling the method, at all.
This can be a problem, obviously. Also, it does not seem consistent to
have a different behaviour when the user clicks on OK in the confirm
dialog, compared to a button without the confirm attribute.
So, with this commit, we just make sure that such buttons save the
record before calling the method, just like other buttons.
As a way to optimize loading, images are not necessarily fetched in db.
They have, in their url a "unique" parameter, which is the last_update date on **the record** and controls on the python-side whether it should get the image from a cache or from the db.
Before this commit, this __last_update field wasn't present in the view, so it wasn't fetched, and writes on a model's image worked but did not refresh.
The image displayed was the old one.
After this commit, when the image field widget is present, we force the loading of the __last_update field of the record.
Upon update, the image displayed is the new one.
OPW 777552
closes#20457
1- When viewing for example journal items.
2- Now activate a filter that would display no record
Before this commit, the column aggregates of case 2 were the same as case 1.
After this commit, we recompute the aggregate, which ever case we are in.
OPW 777660
closes#20452
A list view can display the sum of all values for one field, using the
'sum' attribute. Before this commit, this sum was not updated whenever
a field was changed (but it worked when adding a line).
If the user change a filtered field, the record is not always displayed.
Wrong domain construction. The automatic filter must be use to filter and
remove items from the view for the unselected and not display the selected.
With this commit, we allow an onchange coming from a field to modify the
same field. This was not working for field widgets derived from an
input field.
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.
For instance, open a list view with enough records so that there is
a scrollbar, scroll, open a record of the bottom of the list and go
back using the breadcrumbs: the scroll position should be restored.
Before this rev., it wasn't the case: the scroll position was reset
to the top of the list (i.e. to 0).
This was due to the form renderer which manually triggered the event
DOM_updated on the main bus to ensure that textareas were correctly
autoresized. However, this wasn't done at the right place, and it
impacted the way scroll positions of views were saved/restored.
Indeed, this was only necessary when switching from readonly to edit
mode, i.e. when the form view was actually already in the DOM, but
not at each rendering as they may be performed outside the DOM (and
in this case, the DOM_updated event is triggered by the view_manager
when the view is really appended to the DOM).
Note that this whole scroll mechanism relying on the DOM_updated
event will probably change soon in master, with the refactoring of
the upper part of the webclient.
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.
This use case was not correctly managed as the function evaluating if the
value has changed compares datetime and date.
This triggered an issue if the widget `date` was set on the field `date_order`
on a purchase order for example ; it was not possible to create a record as
the datapoint was set `dirty`.
This rev. ensures that a `field_changed` is not triggered if the day is the same
on a date widget.
This rev. also adds support of `datetime` fields on date widget, which appears
to be a valid use case.
Fixes https://github.com/odoo/odoo/issues/20311
Before this commit, the image was directly built without using the corresponding
template, which set some properties on the image (class, width, etc.).
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.
Opening a record in a calendar view always showed the default form view when it is not a popup.
Example in CRM: opening an opportunity will always show a lead view.
The fix aims to use the "get_formview_id" method to find the right id of the view that must be shown instead
of using a default id.
opw-774272
This commit ensures that tab navigation works properly when editing a
form view that contains input fields with phone widgets. Previously,
pressing TAB would skip those fields.
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.
Before this commit, there was a bug when creating a new record which
contains a one2many with an onchange. The commands sent to the onchange
did not contain the full information.
Here is how you could reproduce the issue: install expense, go to the
expense list view, select the 2 lines, then, in the 'action' menu in the
control panel, choose 'Expense: submit to manager'. In the new expense
sheet, you could see that there were two lines in the one2many
expense_line_ids. However, these lines are empty. The reason is that
the commands sent in the onchange were 2 commands 0, with {} as data.
So, in short, the BasicModel did generate the proper commands, but with
empty data, in the specific case when we have a non empty one2many in a
default_get, then an onchange.
To solve this issue, I had to fix 2 things: the internal data struture
was wrongly updated, and the commands should be generated with all the
data, and not only the changes.
The parsing of the integers does not escape the thousands separator.
issue: Integers are currently not properly parsed. For example, create
a database in Spanish language, install product_expiry and in settings
activate Lots & Serial Numbers. Go to Products and create a new product.
Choose to track by lots and specify the use_time, life_time, etc.
When saving, all integers are set to 0
Since the new views, the field parsing for m2o returns an object with
id and display_name. If the given value to parse is a string, it is
supposed that this is an ID. This was breaking the domain selector
widget which should allow strings as name-strings of m2o values.
We clear the input field when clicking 'Create and Edit' to ensure that
the field is empty if the user chooses to cancel the record creation. If
a record is indeed created, then the field value will still be updated.
Problem occured in the MRP Production wizard (with a consumed
product tracked by serial number). The opened record is a new
record, and its one2many has 2 default rows that are prefilled.
If the user edited one of the quantities in those rows, and set
an invalid value instead (e.g. a letter), the row was removed
without notice when it was focused out. This was because the
model wasn't aware that a change has been done on the record,
and as the record was flagged as new, it was simply abandonned.
The one2many default get code used to meddle with basic_model's res_ids
manually, which ended up desynchronizing the data and res_ids fields
of the list representation of the one2many values.
This commit solves the issue by using the proper mechanisms of the
basic_model, that is creating a proper datapoint for those ids.
Steps to reproduce the original issue:
- Install sale_mamangement, mrp and purchase
- Create a product
- In the Inventory tab, in Routes, uncheck Buy
- Check and then uncheck back any other route than Buy
- Get a traceback because we are looking for a record with a given
res_id in the list data but since they are desynchronized, data
is empty at that point even though res_ids is not.
The o_row class mechanism is supposed to be used to put another
element next to a field, like a button for example. However,
in the case of phone and email field, the o_text_overflow hack
gets in the way.
The problem that o_text_overflow is trying to solve is when you
have a long email, the table used to display the form view fields
tends to use very long cells (td) so it can display the whole email
address. This behavior completely breaks the form view, even though
the email address is clearly set to wrap in css. The o_text_overflow
class is a hack that forces the table to think that the email is
small, then defaulting to the width 50% css rules. If the email is
too long, it is correctly wrapped inside the cell, without breaking
the form view layout.
However, when we need to add a button next to those fields, this
hack gets in the way of the o_row class css rules, completely
wrecking it. We looked for a fix with qsm-odoo for hours but were
unable to find one that did not require a complete rewrite of the
form view css rules. In the end, we decided to remove the hack from
the phone field and keep it on the email field, as we think it is
less common to have a very long phone number than to have a very
long email.
Before this commit, and since the combination of new views + datepicker
library update, the datepicker opened at the top left of the window
when using it in a domain selector. It also could not be used at all.
This was because the current scenario occured:
1) Click on the datepicker
2) The datepicker triggers that it has changed on opening
3) The whole domain selector is rerendered
4) The datepicker computes where it should open... on basis of the
old destroyed domain selector
As the main cause of the problem here was the (2), this commit changes
the datepicker odoo widget to only notifies that it has changed when it
has really changed.
- correctly update the pager when a record is added or removed
- destroy the widgets of the removed row when the user clicks on
'Cancel' when creating a new record
- ensure that the list always contains 4 rows (before this rev.,
in list views with less than 4 records, if the user created a
new record, then clicked on 'Discard', there were only 3 rows
left
- properly destroy field widgets when removed from the DOM
Note that the change of parent.parentID to parent.static is not a
bug fix, but it's better to use the key that indicates the type of
list element, instead of implying it from other attributes.
The FieldDomain allows to open a list in a dialog to display the
records matching the current domain. In this dialog, clicking on
a record should do nothing (this was the behavior before the new
views).
Before this rev., it actually tried to open the record and it
produced a crash.
When the mockserver handles an unimplemented route, it just log an
error. This is annoying because it does not break the QUnit suite, so
if the developer does not look at the console, it will look like the
test suite pass. However, the runbot will see that as an error.
With this commit, we throw an error to force the test suite to fail in
that case.
Before this commit, there was a crash when sorting a one2many in a form view.
This is due to the fact that the event from the one2many bubbled up to
the main form view, which basically assumed that it was supposed to sort
some sub one2many.
It could be seen for example when editing a 'attribute' in a product
form view (need to activate variants), then sorting the 'attribute
values' sub one2many.
With this commit, we simply stop the event propagation at the correct
level.
The `upgrade_boolean` widget should display an `Enterprise` label next to it.
There is however an issue when a `label` is specified for this field. In this case,
the `Enterprise` label should be placed next to the field label (and not the field
itself).
The easiest solution would have been to instantiate the field widget with its label,
but this can't work because the field widget is instantiated before its label.
We thus re-render the widget after its label creation.
Géry Debongnie