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
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
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
In the tests environment, we listen to the 'DOMNodeInserted' event
to remove the src attribute of img and iframe nodes as soon as they
are inserted into the DOM, so that they don't perform RPCs.
However, this listener was bound in the create(Async)View, and
createActionManager helpers only. This rev. moves it to the
addMockEnvironment helper which is more global, and basically used
by all tests.
Moreover, we now listen to the 'DOMNodeInserted' event on the body,
instead of on the widget, as it may happen that some content is
inserted into the DOM outside the widget itself (e.g. dialogs are
appended to the body).
The issue adressed by this fix was observed by a problem with a missing
onchange. The situation only happens when we have a one2many in a form
view with an onchange in a field in the list view, and the arch of the
list view is not inline. In that case, the onchange was not properly
triggered.
There are two causes for this bug:
- the BasicModel does not exactly receive the same data when loading a
record in a one2many with a non inline view. More specifically, there
is a confusion with the fields/viewFields in that case. This is done
because the postprocessing of the fields is slightly different when a
sub view is not inline (not ideal situation, we should fix it btw)
- when it construct a subrecord, the BasicModel did not use the correct
fields value, when there was a subview. More specifically, it used
the view.fields (which does not contain onchange informations) instead
of the view.viewFields (which contains processed/view specific
informations, including the onchange data.
This commit fixes the second issue, because this is clearly a bug, and
it actually fixes the problem. The first issue is actually okay,
because we already have a difference of behaviour between the main view
and sub views (in the first case, we have the fieldget information, not
in the second case, so the processing is already a little bit different
anyway)
Notes:
- This bug was discovered only because we added a test in 11.0, which
was forwardported and broke in master. The breakage occured because
of a recent refactoring in master which moved the arch processing
inside the views and out of the data manager.
- It is good that we discovered this bug, but I want to say that it really
sucks that forwardports are done, break the master/saas.11.2, then I
have to fix it in emergency, and it completely break my own
schedule...
wip
wip
The issue adressed by this fix was observed by a problem with a missing
onchange. The situation only happens when we have a one2many in a form
view with an onchange in a field in the list view, and the arch of the
list view is not inline. In that case, the onchange was not properly
triggered.
There are two causes for this bug:
- the BasicModel does not exactly receive the same data when loading a
record in a one2many with a non inline view. More specifically, there
is a confusion with the fields/viewFields in that case. This is done
because the postprocessing of the fields is slightly different when a
sub view is not inline (not ideal situation, we should fix it btw)
- when it construct a subrecord, the BasicModel did not use the correct
fields value, when there was a subview. More specifically, it used
the view.fields (which does not contain onchange informations) instead
of the view.viewFields (which contains processed/view specific
informations, including the onchange data.
This commit fixes the second issue, because this is clearly a bug, and
it actually fixes the problem. The first issue is actually okay,
because we already have a difference of behaviour between the main view
and sub views (in the first case, we have the fieldget information, not
in the second case, so the processing is already a little bit different
anyway)
Notes:
- This bug was discovered only because we added a test in 11.0, which
was forwardported and broke in master. The breakage occured because
of a recent refactoring in master which moved the arch processing
inside the views and out of the data manager.
- It is good that we discovered this bug, but I want to say that it really
sucks that forwardports are done, break the master/saas.11.2, then I
have to fix it in emergency, and it completely break my own
schedule...
wip
wip
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
In Less, the size_class XXS is defined and used in media queries.
This rev. adds it in JS for sake of consistency.
Code in addons comparing the size_class needed to be adapted due
to the new XXS size_class.
Moreover, we now use the helper 'config.device.isMobile' everywhere
we should, instead of manually comparing the size_class.
Finally, we changed the way the config.device has to be specified
in the test environment. From now on, only the size_class should be
set, and the isMobile flag is computed automatically.
Url in the web client are supposed to open in a new tab. This was the
way it worked in v10.0 and was lost with the refactoring of the new
views.
We just reintroduce that behaviour with this commit.
Closes github issue #22389
A `default_get` for a x2many field can return a new list of commands for one of
its x2many field, like
[[0, 0, {
'groups_id': [[6, 0, [1, 2, 3]]],
}]]
where [1, 2, 3] is a list of existing ids.
This use case was not correctly handled by the BasicModel because
`_makeDefaultRecord` was not recursive.
Closes#22401
When creating a record with many default values, it could happen that
the number of ids returned by the default get (or onchange) exceeds the
limit for the form view.
For example, we can see the issue in the expenses list view. We can
increase the limit in the pager, to a value higher than 40. Then,
clicking on select all, then on 'Submit to manager' in the action menu
will result in a traceback.
The Submit to manager action will trigger a new action with a context key
'active_ids' with a large number of ids. After that, the web client
will execute the server actions, which will return a new action with a
context key 'default_expense_line_ids' with a bunch of ids. Then, it
will attempt to create a form view. This will call the
makeDefaultRecord method in the basic model. This method will generate
the commands for the one2many, for all ids, but will only load the 40
first sub records. After, it will attempt to apply the onchanges, with
some code that assumes that all operations of type 'ADD' correspond to a
local datapoint.
In this commit, we fix the code to properly work with operations of type
ADD with a res_id, but with no id. In that case, we simply generate a
command 'LINK_TO', since the value has not been changed.
opw 804370
Mathieu Duckerts-Antoine