In a one2many, if the user clicked the trash button while editing another line,
the row was not unselected.
Thus the modal was not triggered, which entailed that the currently edited line
was always saved.
In particular, it allowed to give empty values to required fields.
opw 1834346
Here is a scenario that could happen before this commit:
1. go to a list view with more than one record, say 3
2. click on the 3rd record to open the form view
3. the pager says 3/3
4. click on edit button
5. click on discard button
6. the pager says 1/3 (but the record displayed is still the same)
It is often necessary to restore the offset for the sub records, because
the number of pages in a one2many could have changed. However, it is
not a good idea to do that for the main record, since it interferes with
the usual flow of operations.
- Create a vendor bill, save and validate
- Duplicate the bill, save
- Click on "Create"
A customer invoice is created, while the user expects a vendor bill.
After duplication, the new record is loaded but the context is lost.
Since the default value for the invoice type is based on the context key
`type`, a loss of context leads to an incorrect invoice type.
opw-1826453
Co-authored-by: Géry Debongnie <ged@odoo.com>
Before this rev., this attribute was ignored for groups containing
sub groups.
Task 1786309
Closes#23514
Co-authored-by: Mohammed Shekha <msh@openerp.com>
Since the <widget> tag is not used anymore in any of our views, it was
not really properly supported. In particular, the form widget was not
notified when the state of the form view has changed, which makes it
very difficult to actually do any useful work.
With this commit, we make sure that the widget method 'updateState' (if
it exists) is called with the new state whenever it changed.
This should allow developers to do useful work without having to work
around the issue. Note that this is not really a perfect solution, since
the updateState methot may or may not have been implemented.
I think that we need some kind of ViewWidget abstraction, which could be
used to have a better and more complete API for widgets in a basic view.
And AbstractField could inherit from ViewWidget.
Rev. dbdd742 introduced the 'baseMode' parameter of field's nodes
in the BasicRenderer. Its purpose is to encode the generic mode
of the field, regardless of its readonly modifier (i.e. in form
views, the baseMode of all fields is the mode of the renderer and
in list views, the baseMode of all fields is 'readonly', except for
fields in the row being edited, whose baseMode is 'edit').
Unfortunately, when the value of the readonly modifier of a field
was 'readonly', its baseMode was changed from 'edit' to 'readonly',
which shouldn't, as the baseMode's value should not be affected by
the modifiers.
This produced a bug when a field had a readonly modifier, as once
its value became true, the field was rendered in 'readonly', and
whatever the value of the modifier afterwards, it always remained
in 'readonly'.
The rev. ensures that the baseMode is no longer impacted by the
value of the readonly modifier.
Closes#22729
Before this rev., it might happen that the parent of BasicModel instances
wasn't correctly set to the Controller instance. It was actually set to the
ActionManager instance, which is never destroyed. So when this happened,
the BasicModel instance wasn't destroyed when it's controller was.
Revision on 41fe7f9d11
This commit intended to reduce the network load when reading records with
binary fields. This was made possible by enforcing the contextual key
`bin_size` to be set for records with binary fields.
However, it is causing some issues (see #22222, #22231) which are:
- write with bin_size:true generates a traceback
- read/search_read with bin_size:true breaks some images
on some views (e.g. base.view_partner_form)
Since the problems outweight the gain of these changes, we revert them.
Field widgets now have a key 'context' that let them
extend the context of the dataPoint (e.g. list).
In particular, widgets on binary fields enforce the contextual
item {bin_size: True}, so that the server gives the size of the
binary field as its value, instead of its content.
This change on binary fields reduces network load when accessing
a view with binary fields.
Most field widgets are synchronous, but some of them have to do extra
work before being ready (for example, the pad widget, or widget which
needs to lazy load JS/CSS files). Because of that, the new views have
been well tested with synchronous widgets, but not completely with async
widgets.
Some code depended upon the fact that the widget was ready immediately
after being created. This was incorrect, and is fixed in this commit,
by adding a new hook that is called in (basic) views after a widget is
ready (meaning, start and willstart are done)
on pricelist, open a pricelist form
click on one country group [country group form opens]
click on a pricelist again
Before this commit, a traceback appeared, saying the pricelist record was null
YET the pricelist's form on which we clicked before opened.
After this commit, the form of the pricelist opens, and no traceback is thrown.
OPW 783896
[FIX] web: test circular many2many
closes#21148
Since odoo/odoo@da136d8 the modifiers in the widget attrs are parsed.
`stringify` thus needs be to used when displaying them in the debug tooltip (to
avoid to display [Object object]).
The attribute `autocomplete` is set with the jQuery function `attr` but
the test was using the function `prop`.
This seems to work in Chrome but apparently not in Firefox.
Before this commit, asynchronous field widgets (with willStart async),
with a non empty template had a problem: the invisible modifier was not
applied properly.
The reason is that the code that applied the modifiers was called
directly after the widget was 'willStarted'. This means that if this is
async, and if there is a template, the $el in willStart will be replaced
by another $el after, which will remove the invisible modifier.
This was an interesting problem with the pad widget (it is asynchronous
the first time a pad widget is instantiated)
Before this commit, asynchronous field widgets (with willStart async),
with a non empty template had a problem: the invisible modifier was not
applied properly.
The reason is that the code that applied the modifiers was called
directly after the widget was 'willStarted'. This means that if this is
async, and if there is a template, the $el in willStart will be replaced
by another $el after, which will remove the invisible modifier.
This was an interesting problem with the pad widget (it is asynchronous
the first time a pad widget is instantiated)
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.
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.
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.
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.
This reverts commit b94939377a.
The commit was breaking most of the backend checkboxes trying to fix a
frontend one.
On top of the revert, this commit adds frontend-only style to fix the
frontend checkboxes.
Before this commit, the label was into a display block that add a return line
between the cehckbox and the label.
It was not visible in backend, because label by defaut is displayed without
renderCheckbox. (no options.text provided)
Now renderCheckbox render correctly with the same code in frontend and backend
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.
With the new views, we lost a (almost unused and undocumented) feature:
the ability to instantiate custom widgets in a form view, not linked to
a particular field. For example:
<widget type="weekly_timesheet" attrs="{'readonly': [['state', 'not in', ['new', 'draft']]]}"/>
We reintroduce this feature in this commit, with a nice twist: it also
works for the list view and the kanban view.
Before this commit, the xml attributes defined with 'context.get(key)' in the
subviews not inline were not evaluated correctly. This was caused
by the loss of the one context in the '_loadSubviews' method.
This commit fixes this issue and modifies the mockserver in order to be able
to use the parameter 'viewOptions.context'.
When an onchange modifies an x2many field, the line on which the user
works remains in editable mode and the cursor is returned to the same
position.
The second argument of create command is a reference used to reactivate
the edited line.
When the external button of a many2one field is clicked, the
related record is opened in a dialog. When the user clicks on
'Save' in this dialog, a 'reload' event is triggered to reload the
parent view (the one in the background), as the display name might
have changed.
However, when there is another many2one field in the opened dialog,
and if its external button is clicked, there are 2 opened dialogs,
and thus 3 nested form views. If the user clicks on 'Save' in the
third one, only the direct parent view must be reloaded (the one
in the first dialog).
Before this rev., the 'reload' event wasn't stopPropagated, so it
was handled by the view in the dialog, and by the one in the
background, which produced a crash.
This could happen for instance in Sales Order, edit a sale order
line, click on the external button of the product, in the dialog,
click on the external button of the category, edit some field and
click on 'Save'.
Closes#19052
The field 'display_name' is automatically added to the list of
fields to fetch when fetching a record. Before this rev., its
value was also sent alongside the fields in the view for onchange
RPCs. It shouldn't: only the fields in the view should be sent.
It produced a weird bug in the res.partner form view: open a
contact (company), add a sub-contact, save -> the display_name of
the contact was then '' (and 'Contacts' was displayed in the
breadcrumbs instead of the display_name of the opened contact).
This is because 'display_name' was sent to the onchange, which
returned '' as value (because of another bug python side). So as
it's value changed, when saving, the new display_name was sent to
the server (even if this field was actually readonly).
Before this rev., we also always fetched 'display_name' when
fetching list of records (read or search_read). This wasn't a bug
per se, but it might be a computed field, and it isn't necessary,
so we stop fetching it in that case if it isn't in the view (as
it was done in saas-15, before the new views).
This option has been removed with the new views but was used in barcode.
The form renderer was also dealing with some part of the autofocus
but this should only be handled by the controller.
The logic is now only in the controller and a test case has been added.
len-odoo