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 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.
The 'new views' refactoring introduced the usage of the "disabled"
attribute in addition to the associated bootstrap class. As a
side-effect, tooltips are never rendered when the mouse is on a disabled
button, since disabled elements do not fire mouse events.
In particular, no tooltip is shown when hovering over a disabled button
of the statusbar in debug mode. This can be observed when opening the
form view of a Manufacturing Order.
We fix this issue by requiring that disabled buttons in a status bar
never be the target of mouse events, triggering them on their
respective parent elements instead.
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.
The session get_file method should return the value from the
ajax.get_file method, otherwise we lose information (this is necessary
to be able to react properly to the fact that the download was blocked)
Before this commit:
Multiple widgets for the same field on the same view (V11.0 settings) would not
retrieve the correct label but all of them.
Now:
We now retrieve the correct label instead of all of them
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 a user clicks on an input or a select field
in Safari on IOS, Safari has a behavior of zooming-in
on the field when the keyboard opens.
Even after the user dismisses the keyboard, the screen
still stays zoomed-in. The user has to then zoom out manually.
Now, the user is not allow to zoom-in at all.
This is already the case with the Android application.
We now have the same behavior between the two apps.
As can be seen in https://github.com/scottjehl/Device-Bugs/issues/8 a
combination of "-webkit-overflow-scrolling:touch", "position:relative"
and "overflow:auto" can have unexpected behavior on iOS.
The issue solved here is that writing in a form view inside a modal in
iOS (at least version 10.3) would make the whole form body invisible
until edition is ended.
This commit fixes this by adding a CSS rule which avoid the iOS bug.
opw-774396
closes#20314
When a user clicks on an input or a select field
in Safari on IOS, Safari has a behavior of zooming-in
on the field when the keyboard opens.
Even after the user dismisses the keyboard, the screen
still stays zoomed-in. The user has to then zoom out manually.
Now, the user is not allow to zoom-in at all.
This is already the case with the Android application.
We now have the same behavior between the two apps.
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.
Before this commit, when putting the mouse over an attachment in the attachment drop menu list, the date time displayed was UTC only.
After this commit, we convert that value to the correct timezone datetime.
OPW 776704
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.
I don't quite get how it can trigger on user systems (as it apparently
requires resetlocale() to fail to set up an UTF-8-encoded-locale
somehow, disabling resetlocale() is how I could get the issue
triggered on my system), but anyway it's apparently possible for Odoo
to run with an ASCII system encoding, and it turns out Python 3 will
not use UTF-8 everywhere but will rather use whatever
locale.getpreferredencoding(False) yields, which in theory could be
completely bonkers.
This is an issue when using text IO with an implicit encoding, which
is what load_locale (/web/webclient/locale/<lang>) was doing.
* Fix by using binary IO
* Fix (2) by using direct-passthrough IO with specified encoding, that
way we let the WSGI server handle the file streaming
Fixes#20075
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
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
iOS devices need to open a window to allow downloading files. This is
fine, unless the browser is setup to block the popups, which is quite
probably the default settings. In that case, it just fails silently,
and the user has no idea of what just happened.
So, with this commit, we simply display a warning to let the user know
of what is actually going on.
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.
Discarding a new record triggers the 'history_back' action. This makes
sense if the record was discarded from a normal form view, but not so
much when in a modal, where the expected behaviour is to close the
dialog.
This commit overrides the function in the action manager which handles
the switch to the previous view. It checks whether a dialog window is
open, in which case it simply closes it.
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.
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.
Aaron Bohy