... by setting it 'btn-default', because users hesitate between
that button, and those in the control panel.
Task 32950
Co-authored-by: dbh <dbh@odoo.com>
Co-authored-by: aab-odoo <aab@odoo.com>
The initial rev. odoo/odoo@2d3ecf2 that was supposed to handle this use case
was in fact only dealing with one command as default value for nested x2m, not
more.
The basic model can now handle multiple commands.
Closes#24241
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
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
The goal of this commit is to allow fast entry of the same model using
the keyboard for navigating through the form once, by blocking the user
from advancing in the form if there is a required field or once they
went through the form once to get them to a primary action (button)
This commit includes the following changes
1) Enable moving forward from field to field using the TAB key
2) Entering the one to many and many to many using the TAB key
a. When entering it, set the focus on the "add new line" link or
button
b. When adding a new line, set the focus on the field visible
editable field of the new line
c. Discard adding a new line with ESC key
d. If the user leaves the first field empty and uses TAB, we
will cancel the adding of a new line and move to the next
field of the form
3) When a field is required and not filled in, do not allow the user
to move out of the field using the TAB key (the user is still
allowed to use the mouse though), mark the field as invalid
instead
4) After going though the form once, using the TAB key on the last
field will move the focus to the first primary button of the page
5) When the focus is on a primary button (EDIT/SAVE), the user cannot
move the focus forward using the TAB key. Hitting TAB again will
display a tooltip telling to hit ENTER to activate the button.
The mouse is still available to move the focus.
6) When the user saves, the focus is placed on the first primary
button of the form renderer (like VALIDATE for a new invoice)
7) On dialogs, primary buttons should stop the users from moving out
of them, and showing a popup if the user tries
8) When closing a dialog, the focus will be moved back to the widget
that opened it.
This commit does not include the following features
1) Navigation with the keyboard on a selection one to man
2) Navigate between tabs in a form using the keyboard
3) Cancelling the adding of a new line in a many to many using the
ESC key do not set the focus correctly
4) Enhancing the focusses fields (like blue underline)
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
For x2many relational fields(of type kanban), we shoud be able to set custom label for
'Create / Add' button by adding 'create_text' node option on particual field from xml.
Right now, 'create_text' is only handled for many2many fields, preventing users to set
custom label for one2many fields.
This commit allows users to set Create Button label for both m2m and o2m fields.
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
Size attributes (e.g. `max-width`) are sometimes set in css (i.e. with classes,
see `oe_avatar`).
They must however be overriden if they are specified on the widget.
Example:
<field name="image" widget="image" class="oe_avatar" options="{'size': [180, 180]}"/>
The `max-width: 90px` set on oe_avatar must be overriden in this case.
Note that the attribute `img_width` and `img_height` have been depreciated as
`width` and `height` are fulfilling the exact same purpose.
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
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.
The widget statusbar was using an attribute `clickable` on the field widget
to define if the statusbar was clickable.
This attribute is in fact not a field attribute but a widget option so it
has been moved accordingly.
Note that a retro-compatibility adapation is done in the field widget.
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
With this commit, when a phone number is clicked (in readonly),
- if voip is not installed, it opens an app according to the user
choice (e.g. skype), and on mobile, it opens the phone app to
call the number
- if voip is installed, in desktop, it opens voip, and on mobile,
it still opens the phone app to call the number, because webRTC
is not supported.
This commit also makes the employee form view use the phone widget
for the 'Work Phone' and 'Work Mobile' fields.
Task #30369
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.
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
