The progress bar was pretty broken before this commit.
> It was not possible to input the value as text
> Moving the progress bar to modify value and saving crashed
> modifying the max value crashed
> The whole feature was ill-defined
With this commit, we fix the crashed. It is now possible to write the field
behind the progress bar by moving it in RO mode
or by typing the input in RW mode
*if it is the value we want to write on*
It it is the max value that the field targets, we can do it in RO and RW mode,
only with the input as text
Note that this works *only if* the editable option on the widget is set to true
OPW 2061846
closesodoo/odoo#36928closesodoo/odoo#36970
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
There is an open issue on the tempusdominus lib:
https://github.com/tempusdominus/bootstrap-4/issues/223
It occurs when there is a valid value in a date(time) field, and
the user unsets it by setting an invalid one.
This rev. fixes the issue in Odoo by preventing to reach the buggy
piece of code in the lib. In a few words, when the user sets an
invalid date, we reset the previous valid date (which is what the
lib tries to do anyway).
Task 2057009
closesodoo/odoo#36211
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
Before this commit, a field selection which was required
did not have an empty option
ref: 4dfabb8f7a
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:
- 4dfabb8f7a for the selection feature
- d77ce4c2a9 overriding the required attribute of tz in res.user form
OPW 2057913
closesodoo/odoo#35989
Signed-off-by: Lucas Perais (lpe) <lpe@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
closesodoo/odoo#34684
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.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
closesodoo/odoo#34771
Signed-off-by: Géry Debongnie (ged) <ged@openerp.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.
Issue 2027356
closesodoo/odoo#34785
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
When uploading a file to a binary file, then clicking on the
"clear" button, then reuploading the same file...
Before this commit:
The actual input of the field was only changed on user input.
This means that the "clear" action didn't reset the actual value
of the input, and the browser's default behaviour when getting
the same path twice is not to change anything. In the use case,
you couldn't upload the same file until you uploaded another one.
After this commit:
The "clear" action now also clears the value, allowing reuploading
the same file over again.
closesodoo/odoo#33843
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
Before this rev., the datepicker was opened when a date(time) field
was focused (e.g. with keyboard navigation). We don't want this
behavior anymore, and we want the datepicker to open only when the
user clicks in the input. This rev. makes this change.
Moreover, this allowed to refined the keyboard navigation (ESC) in
editable list views: when a datepicker is opened, and the user
presses ESC, we close the datepicker, but we keep the row in
edition, whereas before this rev., the row was switched to readonly.
closesodoo/odoo#32408
Signed-off-by: Martin Geubelle (mge) <mge@openerp.com>
Assume an x2many editable list where the user edits a record (input
field), and then clicks on 'Add a line' (and keeps it pressed for a
while, before releasing the click).
When the 'mousedown' event occurs, the 'change' event is triggered
on the edited field, and (once potential onchanges have been
applied), the list is updated, i.e. all rows except for the one
being edited a re-rendered.
However, the 'Add a line' handler listens to the 'click' event,
which never occurs if we release the click after the rows have been
re-rendered.
This is an issue for every rows, not only 'Add a line', but for
data rows, the issue is already present in former versions, and is
not that easy to fix). The 'Add a line' case is a consequence of
the recent work on list views (see 234d92c4f0), so we can fix it
independently.
Task 1915702
Steps to reproduce the bug:
- Go to any field Date
- Enter wrong date
Bug:
A traceback was raised.
Now a warning is raised and the wrong value is removed.
opw:1974747
closesodoo/odoo#33362
Signed-off-by: Simon Goffin (sig) <sig@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>
This rev. enables the editable feature in grouped list views.
Part of task 1915702
Co-authored-by: Aaron Bohy <aab@odoo.com>
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
closesodoo/odoo#31743
Signed-off-by: Aaron Bohy (aab) <aab@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>
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
Lucas Perais (lpe)