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.
In the reference widget, the focus was always on the input (many2one) even
though the first select (with the model) was not set.
Thanks to @kaerdsar for the original PR.
Partially closes#24070
On a pivot view expand a field in column
another one in row
Then put a domain in the search view
Save the whole thing (ir.filter) as favorite
Before this commit, the ir.filter was not saved the right way when a domain was present
(Let alone its restoration)
This was because of
- the internal default groupbys of the pivot model was not updated, and what we got in the params was overwritten
by what existed before
- a slight typo in the code made the row updated with the col values
OPW 1835865
OPW 1829925
closes#24215
In the calendar view there is some mixing of moment with:
- a local date with given timezone
- a UTC date with added timezone manually applied
The setDate function of calendar model sometimes received either of the
two types, and always transforms them to UTC date with added timezone.
This cause eg. the following issues:
- in the minicalendar, if we click on a day (eg. 12) the day highlighed
will be the one of 12th at midnight with timezone applied. So with a
negative timezone the 11th would be highlighted in the mini calendar
(but the 12th would still be the day shown).
- if we change scale (week/day/month) or open calendar or use next or
previous button: we call `setDate` with a UTC+timezone moment. So each
time this is done, we get an additional timezone
eg. when opening the calendar view on the 12th at 5:00 with GMT-0200:
-> the target date is 12th at 1:00
-> if we set the day mode: target date is 11th at 23:00
-> if we set the week mode: target date is 11th at 21:00
With this change we keep target_date and highlight_date as local date so
setDate always receives a local date and jquery-ui DatePicker gets the
date in the expected format.
opw-1831368
closes#24188
When Odoo display a phone number number, on phone or if VOIP is
installed a invisible `­` character was added from 9.0 up to
saas-11.2 so an applications such as skype would not be concerned with
the number.
But if someone copy-pasted from this to somewhere else in Odoo, we would
get incorrect number with this invisible caracter. So this change make a
special case for the "FieldPhone" so the character is removed from data
saved.
opw-1834858
closes#24223
Before this rev., a crash occured when a default_get returned a
command 0 (CREATE) for a one2many, with a value for a date(time)
field (e.g. [0, false, {some_date_field: '2018-12-08'}]). This
was because the related values (inside the commands) weren't
parsed. This only impacted date and datetime fields, for which the
parsing converts the string into a moment instance.
Fixes#23672
Have the create_date field displays on a one2many list
Try to add a record onto the list
Before this commit, when the virtual record is added onto the list
it crashes because the datetime field is undefined and cannot be parsed
After this commit, It doesn't crash though the value would have to wait the save on the main record
to be updated (because it is the create_date)
OPW 1834250
closes#24097
Consider the following scenario involving a one2many list (non
editable) inside a form view:
- click on 'Add an item', a model opens,
- fill the fields and click on 'Save & Close',
- reopen the freshly created record,
- maybe make some changes (this is optional, but makes sense),
- click on 'Save & New',
- fill the fields and click on 'Save & Close',
-> the second created record isn't added to the list.
The problem comes from the fact that when the dialog is opened for
the second time (in this case by clicking on a record), the 'save'
handler registers an 'UPDATE' command. While this is correct for
the 'Save & New' click (as we update an existing record), this
isn't for the second record which doesn't exist yet, and thus
requires an 'ADD' command.
This rev. ensures that the two cases are handled in the 'save'
handler given to the dialog.
OPW 1829723
In a kanban grouped by many2one with a progressbar, after emptying a column
by moving all records, the column wasn't correctly updated. This was causing,
in the best case, a record duplication or, in the worst case, a traceback.
This issue comes from the fact that, with a progressbar, a read_group is
performed each time a record is moved. When the group (column) becomes empty,
the read_group won't return this group even though the group still appears in
the kankan. When moving back the record in this empty column, there is a
desynchronization between the kanban controller data and the model.
To fix this issue, an option `keepEmptyGroups` is passed when performing the
mentioned read_group ; this mimics the kanban display that keeps empty groups
displayed and there is no desync anymore.
Fixes#23982
To reproduce the error, go to Accounting > Import Statement, then
Cancel. An error occurs because `belongs_to_company` is not in the data.
Indeed, it is directly set on the action
`open_account_journal_dashboard_kanban`.
Commit 9961bbf4eb re-evaluates if a record should be displayed in the
Kanban view after applying an action (in particular, archive a record).
However, the domain evaluated might contain values which are not in the
data. This is for example the case if there is a domain on an action.
Fixes#24142
opw-1835216
opw-1835123
When a user click on an action button, we need to check if the record
match with the domain to remove it from the view if this action change
the record value.
Special case: we filter by active field equal true, if the active field
is available in the data (field present in the kanban view).
opw-1832879
Co-authored-by: Nicolas Martinelli <nim@odoo.com>
Before this commit, when some records were created from an `onchange`,
we have the following weird behaviour:
Suppose that this record has some required fields that are empty.
When we click on this record, then somewhere else, the record
disappears from the list.
This is because the records contains invalid fields, and it is wrongfully
assuming that the record to be discarded comes from "Add an item".
A previous commit [1] fixed a bit this issue with `default_get`, but since
it relied on a fragile heuristic, we decide to apply the correct fix with
this commit.
[1] https://github.com/odoo/odoo/commit/b09f0c99be2b13d33986414485556d87da186d65
- 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 commit, some breaking spaces were present in the js code.
Such spaces are misinterpreted and worked by luck.
This has become a problem with exported js bunldes (e.g. the
external_lib bundle in im_livechat).
This commit replaces breaking spaces by regular spaces.
Steps to reproduce the issue in 11.0 Enterprise:
- Go to the language English
- Remove from the time format the seconds
- Refresh the page
- Go to sales
- Create a sales order;
Bug:
- You get the warning message
closes#23596closes#22027
opw:1829577
Have a form view with a O2M.
The model at the 'many' end has a reference field
Have a record of the second model display in a modal
(by clicking on a record in the o2m list)
Before this commit:
The field reference was not filled up
This was because the fields to fetch on the modal creation weren't correctly set.
Obvisouly, it also created problem when trying to change the record on the modal:
spawning tracebacks because the reference field was not present in the local datas
After this commit:
The display of the reference field is as expected both in the original form and in the modal
OPW 1829822
closes#22468closes#23896
- Set the OS timezone to GMT-6
- Create a project task with a date deadline on D day
- The tasks appears at D-1 in the calendar
This was supposed to be fixed with 0c0fb63b0d, but actually no.
opw-1815446
opw-1828130
Have a list with readonly modifiers on at least one column.
Have the first record of the list be readonly as computed by the modifier
Create and edit a second record
Enter a value in the cell and hit TAB
Before this commit:
The focus on the targetted cell was lost and the rendering of the cell was in mode readonly
This was because the baseMode of the modifier dict was applied to one and only one node (== one column) and hence to *all* the records
After this commit:
The rendering and keyboard TAB navigation works as expected in the list editable
The baseMode concept has been sharpened and each cell now has one
OPW-1816569
OPW-1824979
closes#23809closes#22859closes#23436
* [FIX] web: Make accessible with keyboard the delete button on o2m fields
Currently, the delete button in one2many fields (trash icon) is not
reachable when using the keyboard, because it's neither a link, nor a
button or any other interactable HTML element, but a `<span>`.
This change causes that button to be an actual HTML button keeping the
same appearance, so it may be reached when using the keyboard.
* [FIX] web: Modify test to expect button instead of span as o2m trash icon
Since buttons to delete records in o2m fields (the trash icon) were
changed from `<span>` to `<button>` to be able to access them with the
keyboard, the test need to be modified so it expect the new element
type and doesn't break.
Have a model with a m2m (field A)
this m2m has also a m2m (and displayed as m2m tags in the view) (field AA)
Have a domain on field A, to trigger the search view selection
Click on add an item
Select everything in the modal, making sure that there is more than 40 records
Click on Select
Before this commit:
There was a traceback indicating the local data did not contain records >= 40
This was because the internal data repository was constrained by a limit
After this commit:
We adapt the limit of the local data repository and there is not traceback
OPW 1823400
When we discard an element, we want to make sure that the new state is
not corrupted by previous user operations. In our case, we possibly had
a limit and an offset values modified by the user.
This could lead to unpleasant situations, with incorrect data displayed
on the form view.
Note that this actually fixes a new bug introduced by commit
https://github.com/odoo/odoo/commit/e7fab234201e357da52c3576ad2e8fc9ceee9359
(this is the commit that introduces the tempLimitIncrement attribute)
The issue here is quite simple. If we are editing a multipage one2many
field, then we click on the pager, we need to properly unselect the
current row.
If we do not do that, then we can enter invalid data. For example,
assume that there is a readonly field. We click on add, it creates a
(virtual) record with no value for that field. When we click on the
pager, we select the next page, and bypass all validation.
When we are in the process of adding a record, we do not want to update
the pager count. The reason is that if the user is at the limit (so,
1-40/40, no pager visible), then click on add, there will be a pager
shown with 1-40/41. Now, imagine that the record currently being added
as a required field, and the user clicks on the pager. In that case, we
need to discard the newly added record (bringing the total back to 40),
then move to next page, which does not exist anymore.
So, to fix this issue, we simply consider that a record being added
does not count, from the point of view of the pager.
On an editable line with a many2one
Click to create a record
Click on create a record in the many2one
It opens the form view of the object in a modal, which has a many2many list, which choices are domainized
Click 'add an item' on this list
It should open a modal with the filtered choices
Click on any of the existing record
Before this commit:
There was a traceback in JS
That was because the event bubbled up to a parent, when it shouldn't
After this commit:
The whole flow unfolds without errors
OPW 1823205
Before this rev., this attribute was ignored for groups containing
sub groups.
Task 1786309
Closes#23514
Co-authored-by: Mohammed Shekha <msh@openerp.com>
A big problem with the o2m edition happens when the user has a full page
(so, in general, 40 records) and click on add.
If the o2m is in editable="bottom" mode (which is actually a really
common usecase), then the next record will be added at the end.
However, since we have a limit of 40, it will immediately go to the next
page.
The effect is even weirder when there is a required field in the tree
view. In that case, the new record appears correctly, the user can edit
it, then, as soon as the required fields are set, it will immediately
disappear from the current screen.
In this commit, we have a really simple solution: we simply increase the
limit in this case. An interesting thing is that it is actually temporary:
when the user goes to the next page, the limit is back to its original
value (due to the pager click: it resets the value to what the pager knows).
The 'toggle_button' widget is one of special field widgets that
can trigger changes in readonly mode (in this case, toggle the
boolean value when clicked). It was working fine in form views in
'readonly' mode, as in this case, the new value is saved directly,
and the form view is re-rendered (a new widget is created with the
new value).
However, in 'edit' mode, the value isn't saved directly (the user
has to click on 'Save' to save the changes), the widget is reset
with its new value, and the reset wasn't correctly handled in this
particular widget.
Fixes#23400
Before this commit, images in kanban view of the Contact app were not displayed
on non-latin languages, such as Russian.
This was caused by the is_bin_size helper that wrongly assumes that a certain
string is not a binary size, although it is (e.g. 64.2 Кб).
This commit fixes the issue by including such strings as valid binary sizes.
Bug found and fixed by @true-datura
Test by @alexkuhn
closes#23526closes#22519
In some cases, the footer in a form view dialog could be duplicated.
The reason was that the form view was rerendered completely, footer
included, by the renderer, out of the formcontroller control (it is the
formcontroller's job to move the footer buttons to the footer).
A possible fix is to work on the form renderer to make it aware that the footer
buttons are expected to be only rendered once, but it has the disadvantage to
be a fix specific to this issue, and any other form view behaviour with some
side effects may have the same issue.
This commit tries to prevent the form view from rerendering itself
completely in those cases. This also has the disadvantage of possibly
not being a complete fix, if some edge cases are missed. However, I
have the feeling that we still want to avoid rerendering the full view
if possible.
Before this rev., it crashed when trying to create records of the
res.users model. This is due to commit ad1cceb.
The 'default_get' of 'res.users' always returns a value for field
'groups_id', whereas the docstring of 'default_get' states that it
only returns default values for fields given in arguments.
Rev. ad1cceb changed a bit the way the result of 'default_get' was
processed, by iterating over the values instead of over the fields
in the view. So, before ad1cceb, 'groups_id' was simply ignored,
and after, the BasicModel tried to process it and it crashed when it
attempted to retrieve its fieldsInfo, as this field isn't in the
view.
This rev. restores the previous behavior.
Fixes#23303Fixes#23305
Let's assume a one2many displayed over several pages with a default
order such that a record, say R, that would normally be on page 1
is actually on another page. Moreover, there is an onchange on that
one2many which converts all commands 4 (LINK_TO) into commands 1
(UPDATE), which is standard in the ORM.
When the first line of the one2many was edited, the record R was
fully loaded, whereas it shouldn't have been (as it is not on the
current page). So basically, a useless read was performed.
Moreover, if there was an x2many field in the one2many list, a
crash occurred because relational data of R that shouldn't have
been read wasn't postprocessed by the BasicModel.
The useless read occurred because the one2many subrecords weren't
correctly sorted before checking if some of them/some of their
fields should be read. This is not the case anymore.
OPW-1816800
Let's assume a one2many list view inside a form view, displaying
a single char field A. There is an onchange on the form view
returning a command 0 (CREATE) for the one2many. The command 0 only
specifies a value for field A. The one2many list isn't editable, so
when a sub-record is clicked, it is open in a form view (in a
dialog). In this form view, an x2many field B is displayed in a sub
list or kanban view.
Before this rev., it crashed when the user tried to open the
created one2many sub-record (returned by the onchange) in the form
view, because of the presence of the x2many field B, which wasn't
correctly processed by the BasicModel (its value was undefined,
whereas it must be a valid, empty, dataPoint).
Moreover, the limit of the x2many field B wasn't set, so a pager
was displayed as soon as it contained at least one record.
Fixes#22050
Before this rev., an issue occurred on grouped editable list views
that became ungrouped after a reload (i.e. when the grouped part in
the search view was removed). In this scenario, the click handler
outside the list used to leave the edition wasn't bound (because
the list was grouped at the beginning, and thus not editable). So,
it was impossible to leave the edition, even by clicking on 'Save'.
Fixes#23061
When onchange RPCs return a command 4 (LINK TO), the res_id of the
record to link is given, and the BasicModel has to read the fields
in the view for that record. When one of those fields is an x2many
(for instance, displayed with widget many2many_tags), the
subrecords in the relation must be read as well (at least their
display_name).
Before this rev., this last part wasn't done by the BasicModel, and
as a consequence, the many2many_tags widget was always empty, even
though there were records in the relation.
Same thing applied to reference fields, but this is way more
uncommon.
This rev. ensures that x2manys and reference fields are correctly
fetched in this scenario.
Before this commit, there is an issue with one2many lists with records that
have been created on 'default_get': if the record has a required field that
is empty, when the user clicks on this empty required field and then somewhere
else, the record is removed from the list.
The cause of this bug is that these records have invalid field changes, here
the required field that is empty. As a consequence, it checks whether the
record is "new", and if so, removes it visually from the editable list.
(Note: a record is "new" when it is not stored in DB).
This behaviour is expected when discarding records created from "Add an item".
However, that is not intended for records that have been created as default
items of the list. These records are still considered as "new" items, because
they are not stored in DB, but they should stay in the list on discard.
This commit solves the issue by making an additional check before assuming
that the record for which we discard changes comes from "Add an item":
if the record in the list has been created before user interacts on the list
(in other words, the record has been added in the list when the user accesses
it), then we should not remove the record from the list, even though the record
has some invalid fields from the savepoint (e.g. empty required).
opw-806650
Create a new column in Project, add a record and then hit 'Archive Records' : a
traceback occurs.
When creating the new column, the `groupedBy` attribute on the datapoint is set
according to the parent list datapoint, which makes no sense as the records are
not grouped inside the column.
The mentioned attribute is now removed as the records cannot be grouped inside
the column.
Before this rev., the aggregates values displayed in the footer of
list views were formatted according to the field type, and the
field's widget was ignored, whereas it should be used by default.
For instance, if the 'float_time' widget is set on a float field,
the sum should be formatted as FloatTime as well.
Closes#22724.
Before this rev., the list of selected records wasn't correctly
reset when the list was reloaded (e.g. when coming back using the
breadcrumbs). In the UI, the records weren't selected anymore, but
in javascript, the list of selected records wasn't empty. As a
consequence, the aggregates were wrongly computed, and always
displayed 0.
Closes#22725.
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.
This is a small correction of odoo/odoo@3aad756 ; a traceback occured when ESC
was pressed in a list view with modifiers.
The `confirmChange` was done on the parent datapoint (of type list) which has no
attribute `evalModifiers`.
`confirmChange` is now called on the record datapoint. Note that for x2m, it
means that all modifiers linked to the parent record won't be re-evaluated (but
this wasn't probably intended as this is a bit overkill).
Closes#22718
A traceback was occuring when downloading the pivot view without data.
The export function expects the attribute `main_row` set on data, which
is defined in `_prepareData`. The latter wasn't called because of the `return`.
Closes#22728
From a form view (say Bill of materials)
Edit the form
Click on a bom line
Click on the external button that makes the product form pop up
change the order of suppliers on that product
Before this commit, a JS traceback was raised
This was because the changing object was not present in the localData that the Model object holds
or more accurately, it was not the **right** model object that was targetted
and this was due to the propagation of the resequence event
After this commit, no error is thrown, and the resequencing works as expected
OPW 807196
Géry Debongnie