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>
Before this commit when user want to add multiple record at that time
they only allow to add one record at a time.
After this commit user can add multiple record from search more wizard.
Added function _getSearchCreatePopupOptions so that it can be overridden
in FieldMany2ManyTags, options for FieldMany2ManyTags will differ, like
FieldMany2ManyTags SearchCreateDailog should have multi record selection,
Many2ManyTags' SelectCreateDialog should display record other than selected
This commit is related to task id: 1945912
closesodoo/odoo#32453
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
Co-authored-by: Mohammed Shekha <msh@openerp.com>
The pdf_viewer widget fails to load file and hence shows error.
This is due to the wrong controller called(wrong URI passed),
while loading a file using pdfjs.
For files other than images, /web/content controller should
be called since since odoo/odoo#31811.
This is similar to the enterprise fix 793c76298a2b301a2
task-1932190
closesodoo/odoo#33354
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
For signature field widget, we can set 'full_name' node option, which can be
used to auto fill the sign. However, current implementation for getting data
for field provided in 'full_name' (mainly, a string) has some flaws.
For example :
-In case of m2o fields, the string is not properly fetched due to different
structure than regular 'input' fields
- In case of x2m views inside a form view, field with same name can exist in
both parent record and child records. This is already the case with form view
of res.partner, where 'phone' field is there in both parent's form as well as
children's kanban view (for field 'child_ids'). With current implementation,
if we add signature on the form view, and set 'phone' as 'full_name' node
option, instead of form view, we will get phone number from 'child_ids'.
This commit improves the behavior by getting data from the 'recordData' instead
of searching them from the DOM. To have recordData in it's latest state, we've
set 'resetOnAnyFieldChange' flag to true.
task-1948364
closesodoo/odoo#33105
Signed-off-by: Martin Geubelle (mge) <mge@openerp.com>
Rev. a3489be33 removed this feature to fix a bug (when the single
line many2one, e.g. a product, is too long and displayed over
several lines). However, we (fp) still want this for res_partner
many2ones with show_adress.
This rev. re-introduced the feature without re-introducing the bug.
closesodoo/odoo#33139
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.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
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
Aaron Bohy