On a form view:
- we open a modal form view
- in this modal we open a modal form view
- we close that second modal
=> the modal is closed and the first one is still opened, but on mobile
we can't scroll to above or below the modal.
This is because bootstrap remove .modal-open class on body when we close
the second modal, but this class is necessary to scroll (this is not
much an issue on desktop since scroll is often not necessary).
We already had a fix that was weakened in 02a063fd73.
With this changeset, we keep .modal-open as long as a modal is opened.
Without the change, added test failed with:
10. Modal is said opened (expected: true, result: false)
opw-1948423
closes#32106
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Before this commit, there were a crash if you tried to add an optionnal
product in a new sale order without saving it.
Apply same logic as in the ListRenderer: buttons with type="object" are
disabled for no saved yet records, as calling the python method with no
id would make no sense.
To avoid to expose this logic inside all Kanban views, we define a
specific KanbanRecord Class for the One2many case.
This could be refactored to prevent from duplicating this logic in list
and kanban views.
Original Task ID: 1945006
closesodoo/odoo#31695
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
The widget handle was displayed on x2m fields in form views, even when
the field was readonly, which makes no sense.
It is now correctly hidden.
Fixes#30580
opw-1937833
closesodoo/odoo#31743
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Let's assume a many2one field with a lot of possible values. The
user clicks on 'Search More...'. In the opened dialog, only 160
records are available (their ids have been obtained with a
name_search, with the optional text the user could have typed in
the many2one input).
Before 4cd379cf, that extra domain on ids was removed automatically
as soon as the user interacted with the search view in the dialog.
This was especially useful when there were more than 160 records.
However, this was rather an happy coincidence than a designed
feature.
From 4cd379cf, the ids selection was added to the initial domain
of the list, so they couldn't be removed from the domain
afterwards. The user was thus stucked with its preselected 160
records.
This rev. doesn't restore the former behavior, but rather improves
the current one, as follows:
- when there is no text in the many2one input (i.e. no value to
filter on), we bypass the name_search, s.t. all records are
available in the dialog
- when there is some text in the input, we perform a name_search (as
before) to get a list of record ids, and we add a special filter
to the search view in the dialog (the filter on those ids), s.t.
the user can remove it if he wants to access the remaining records.
- finally, the limit is now set to 320, to mitigate the problem
Issue reported on the saas-12.1 migration pad.
closesodoo/odoo#31232
The widget has been moved in rev. odoo/odoo@15f3bbe but was not very generic.
In particular, there was a traceback when clicking on the button if the field
had no value (the button was displayed for readonly fields in create mode).
The button is now only appended in readonly mode (a `button` inside an `input`
or a `textarea` is not very DOM friendly) if the field has a value.
Task 1941996
closesodoo/odoo#31635
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
For many2one fields, 'default_get' only returns the id, whereas
'onchange' (like 'read') returns an array with id and display_name.
Before this rev., when creating a new record, we always called
'name_get' for all many2ones, whether or not their value was
obtained by 'default_get' or 'onchange', i.e. even if their
display_name was already known.
It may just look like unnecessary RPCs, but those RPCs could
actually cause a crash when the user has access to the main model
(and thus can access the display_name of the many2one thanks to
related sudo), but doesn't have access to the many2one comodel.
closesodoo/odoo#30892
Before this rev., the context specified on an x2many fields (in the
arch) wasn't fully propagated to the subrecords. This means that it
couldn't be used, e.g., in the template of the sub kanban view (see
parent commit).
PR: #30881
When using the datepicker with norwegian locales, the dates are
correctly formatted using the norwegian locale but the name of
the months are shown in english. This cause a date validation
error and thus it is not possible to change the date.
tempusdominus.js uses moment.js to deal with dates, it sometimes
copies/creates some and set their option according to the ones
given at instantiation time and fallbacks on default options for
that are not set.
opw-1922437
closesodoo/odoo#30276
Before this rev., a crash might occur when the user quickly
switched twice between pages (e.g. go to page 2, then page 3) on a
slow network.
In the given example, when data of page 2 returned, the list was
re-rendered. Unfortunately, the offset of that list' datapoint was
already changed due to the switch to page 3, meaning that the view
tried to render a page that wasn't loaded yet, leading to a crash
if there were modifiers to evaluate, or to empty records being
displayed.
This rev. ensures that the view is rendered with the data of the
page it expects.
closesodoo/odoo#30150
Start on the modal obtained by a "search more". The offset is never reset.
So suppose you are on page 2, looking at record 81-160.
Do a research that gives less than 80 records.
The result of the search is nothing, since is has been done with a 80 offset.
It should be reset to 0 when we do a new search.
opw 1920826
closesodoo/odoo#30109
Most operations on X2Many widget possibly propagates a field context
(name_create, name_search, ...) but the original read or read on an
onchange does not.
With this changeset, the field context is also used in these instances.
The assertions added in the added test failed with:
expected: ["world"], result: [undefined]
expected: ["world","world"], result: [undefined,undefined]
fixes#29203
opw-1914466
closes#29866
When a percentage if formatted, the decimal separator used is always
`.`, while it should be the decimal separator of the language.
opw-1908220
closesodoo/odoo#30030
Fine-tuning of commit e7fab23420
In a one2many with more than one page with a limit of k records, add a line l.
It increments the list limit to k+1. Remove a line above (of index <= k).
It will try to load a line l' to replace it, that it will find on page 2.
However when deciding if it should read missing fields on that record, it will
scan at most u records, skipping virtual ids.
Here u is the min between the current number of lines and the list limit
without the temporary increase due to the added record.
Since there are at least two pages, u = k.
However since l is in the list at index k, then l' won't be read, and since it
was on page 2 its data hasn't been loaded.
Therefore the js would traceback when trying to evaluate it.
opw 1913361
closesodoo/odoo#29338
Use case: a x2m (ex: attribute values) displayed in a x2m (ex: attributes on
product) using different fields in different views (ex: tags in product form view
and list in product attribute form view). When opening the x2m record (in a
wizard) then going back on the form view, the tags are empty because the
`display_name` value has been lost when fetching x2m for the second time.
In this case, the list `fieldsInfo` needs to be updated with the existing
(default for tags) one so all the fields will be correctly loaded.
Task 1916891
closesodoo/odoo#29598
This branch introduces a large-scale reorganization of the
component tree generated by the web client. The short version is
that now, the control panel is a child of the view controller and
no longer a sibling. Graphically (and simplified), we go from
this:
webClient
/ | \
... ... actionManager
/ \
controlPanel viewController
/ \
to this:
webClient
/ | \
... ... actionManager
|
viewController
/ | \
ControlPanelController
/ \
CPRenderer CPModel
The motivation is that this work moves the code where it should be.
Before this commit, it was kind of weird to have code in the
controllers to render buttons outside of their root node (in
renderButtons). Also, the action manager had to take care of
coordinating search view states between view transitions.
So, this work simplifies the code. It also makes it easier to
extend. We see day after day that Odoo needs to take care of more
complex UI needs, and in many cases, these needs were quite
difficult to implement (we prefer spaghettis in our plates, not in
our code). The changes in this branch should open the way to
implement these features.
For example,
- it will now be easy to add the possibility of views (for example,
the search view or a new ControlPanel view) to add custom buttons
(of type action or object) in the control panel.
- Another need will be to serialize/ restore the state of the
search view across action boundaries (needed by the dashboard).
- Another example is the possibility for views to customize easily
the presence/absence of sub menus (filters/groupbys/favorites/
time range/...)
- Another need is an easier way for views/client action to customize
their control panel.
This commit also contains a large rewrite of the search view (so it
is more inline with our architecture and easier to maintain).
Part of task 1893568
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Martin Geubelle <mge@odoo.com>
Have a one2many display records in a kanban subview,
which opens a form view when edited.
Edit a field displayed only on the form view.
A call to _applyX2ManyChange is done without giving it the viewtype argument,
therefore the fieldinfo is taken from the wrong view, traceback ensues.
opw 1914163
closesodoo/odoo#29607
Recent works in the orm (see [1] for example) changed the behaviour of
the server in the case of onchanges: it tries to optimize Odoo by
sending a minimal diff to the web client in onchanges.
Concretely, this means that the web client receives commands 4 (link to)
instead of command 1 (update + record data). It also sends a minimal
diff in that case. This is a big issue for the web client, because it relied
on the knowledge of the data from the command 1 to be able to evaluate some
modifiers.
The good news is that we can mitigate the issue in one case: we do not
actually need to evaluate the modifiers in the case of a command 4
(comming from the server), because we can assume that the record is
valid. So, we simply bypass the check in that case.
Note that this should fix most of the problem, but a deeper problem
still remains: a crash can still happen when an onchange modifies a
record in a one2many (but in a different page), and we also have a
modifier which needs to be evaluated.
opw: #1904514
[1] https://github.com/odoo/odoo/pull/29086closesodoo/odoo#29172closesodoo/odoo#29086
Recent works in the orm (see [1] for example) changed the behaviour of
the server in the case of onchanges: it tries to optimize Odoo by
sending a minimal diff to the web client in onchanges.
Concretely, this means that the web client receives commands 4 (link to)
instead of command 1 (update + record data). It also sends a minimal
diff in that case. This is a big issue for the web client, because it relied
on the knowledge of the data from the command 1 to be able to evaluate some
modifiers.
The good news is that we can mitigate the issue in one case: we do not
actually need to evaluate the modifiers in the case of a command 4
(comming from the server), because we can assume that the record is
valid. So, we simply bypass the check in that case.
Note that this should fix most of the problem, but a deeper problem
still remains: a crash can still happen when an onchange modifies a
record in a one2many (but in a different page), and we also have a
modifier which needs to be evaluated.
opw: #1904514
[1] https://github.com/odoo/odoo/pull/29086closesodoo/odoo#29172
The current implementation of the state_selection widget always makes it
editable even if the field is readonly.
We improved this behavior by removing the handle of click on the widget
when the field is readonly, but keeping it even if the view is not in
edit mode, because it used for example in project to change state even
when view is not editable.
closesodoo/odoo#29218
Have:
- Model A with a x2m to model B
- Object A with multiple objects B in x2m (that will be sorted)
- On the list view of model A, click on a column to sort by a field
- this field shall not exist in B
- open a record A (towards form view)
Before this commit, the sorting of the x2m crashed, because the key orderedBy was propagated
Due to commit e713ed2a69
After this commit, it doesn't crash
OPW 1913133
closesodoo/odoo#29094
Christophe Simonis