| Age | Commit message (Collapse) | Author |
|---|
|
Before this commit, a field selection which was required
did not have an empty option
ref: 4dfabb8f7adde06a7936502af61534c9958ed4f7
This is fine, but overlooked the fact that modules can modify
the required attribute, or even views can do it
So, we may end up in a situation where the field is required but set to false
This configuration is problematic, at least for the timezone selection field
(see OPW)
After this commit, the empty option is just not visible
note that `disabled = True` would not work because val is not accessible
Because of commits:
- 4dfabb8f7adde06a7936502af61534c9958ed4f7 for the selection feature
- d77ce4c2a92c1da48150e4e84b714dd93f64847d overriding the required attribute of tz in res.user form
OPW 2057913
closes odoo/odoo#35989
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
|
|
closes odoo/odoo#35119
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
|
|
|
|
When opening a dialog using mouse and closing it, form_dialog_discarded is
triggered, which tries to set focus on form while lastActivatedFieldIndex
is -1, as dialog is opened using mouse directly
do not set focus back to form widget if lastActivatedFieldIndex is -1
task-2031706
closes odoo/odoo#34684
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
|
|
closes odoo/odoo#34901
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
|
|
Let's assume a one2many field (editable list) in a form view with
a many2many (e.g. many2many_tags), and an onchange on the one2many
such that, when a row is added to the relation, the server returns
update commands for (a subset of) the records being already in the
relation. For thoses updated records, the many2many field needs to
be read (the onchange only returns the ids in the relation).
Before this rev., the many2many field was read independently for
each record in the one2many. This could cause a performance issue
on large relations. For instance, this was the case on
account.invoice records with a lot of lines.
This commit must be forwardported up to 12.2, not further.
Issue 2027356
closes odoo/odoo#34771
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
|
|
This rev. changes the layout of *editable* list views to a fixed
layout. This means that we are now responsible of the width of
each column. To do that, we associate with each field type a
factor, and the higher the factor is, the larger the column will
be (w.r.t. the others). This default value can be overriden in the
arch.
The fixed layout allows to remove the absolute positionning of
widgets inside editable lists (done in the next commit).
Part of task 1915702
Co-authored-by: Martin Geubelle <mge@odoo.com>
|
|
|
|
|
|
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>
|
|
|
|
|
|
|
|
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
closes odoo/odoo#31743
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
|
|
closes odoo/odoo#32088
Signed-off-by: Christophe Simonis <chs@odoo.com>
|
|
closes odoo/odoo#31790
Signed-off-by: Christophe Simonis <chs@odoo.com>
|
|
It allow not matching the dropdowns of the search view.
closes odoo/odoo#31738
Signed-off-by: Christophe Simonis <chs@odoo.com>
|
|
|
|
Part of task 1896658
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Christophe Matthieu <chm@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: David Monjoie <dmo@odoo.com>
Co-authored-by: Martin Geubelle <mge@odoo.com>
Co-authored-by: svs-odoo <svs@odoo.com>
Co-authored-by: Vincent Schippefilt <vsc@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.
closes odoo/odoo#30892
|
|
|
|
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.
closes odoo/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
closes odoo/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
|
|
|
|
|
|
|
|
|
|
|
|
Fine-tuning of commit e7fab234201e357da52c3576ad2e8fc9ceee9359
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
closes odoo/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
closes odoo/odoo#29598
|
|
|
|
|
|
closes odoo/odoo#30045
|
|
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
closes odoo/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/29086
closes odoo/odoo#29172
closes odoo/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/29086
closes odoo/odoo#29172
|
|
|
|
|
|
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 e713ed2a69af9fe97fbe2d54843adc8f1ce689aa
After this commit, it doesn't crash
OPW 1913133
closes odoo/odoo#29094
|
|
|
|
Oversight of previous forward-port
|
|
|
|
|
