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
With attribute 'on_create="quick_create"' on the arch's root node,
kanban views open the quick create widget in the first column when
the user clicks on 'Create' (in the control panel), if the view
is grouped and if there is at least one column. However, this
column may be folded.
Before this rev., the quick create was inserted into the folded
column, which didn't look amazing. This rev. first toggles the
column before inserting the quick create.
Before this rev., it crashed when the user used the quick create
to create several records (very quickly, or on a slow network),
e.g. on crm.lead (there must be a date field on the kanban record
to reproduce the crash).
The crash occurred when the 'read' RPCs for the created records
return misordered. For instance:
1) 'name_create' record 1 (called and returned)
2) call 'read' for record 1
3) 'name_create' record 2 (called and returned)
4) call 'read' for record 2
5) 'read' for record 2 returns
6) 'read' for record 1 returns
At step 5, the kanban column was updated with the new state, but
this state already contained record 1, which wasn't fetched yet.
This rev. ensures that the created records are added to the state
once they are fetched and ready to be displayed, not before.
Introduce back part of `formatBinary` that was reverted with 7813a8e7.
When an image is unset, the value was `false` which would end up with a
bin_size of `NaN Bytes` which would end up displaying an error image
with source `data:image/png;base64,NaN Bytes`.
This commit get back a previous behavior so the bin_size when the
attachment does not exist is an empty string (so: '').
opw-805542
closes#22348
Revision on 41fe7f9d11
This commit intended to reduce the network load when reading records with
binary fields. This was made possible by enforcing the contextual key
`bin_size` to be set for records with binary fields.
However, it is causing some issues (see #22222, #22231) which are:
- write with bin_size:true generates a traceback
- read/search_read with bin_size:true breaks some images
on some views (e.g. base.view_partner_form)
Since the problems outweight the gain of these changes, we revert them.
Field widgets now have a key 'context' that let them
extend the context of the dataPoint (e.g. list).
In particular, widgets on binary fields enforce the contextual
item {bin_size: True}, so that the server gives the size of the
binary field as its value, instead of its content.
This change on binary fields reduces network load when accessing
a view with binary fields.
For kanban views with attribute 'on_create="quick_create' set on
their root node, clicking on 'Create' in the control panel should
open the quick create widget in the first column if the view is
grouped and if there is at least one column displayed.
It was working as expected, except when there were no record yet.
This was because the kanban controller used the 'state.count'
attribute of the state (which indicates the total number of records
in the group), whereas it should have used 'state.data.length'
(which is the number of columns).
Before this rev., when quick creating a record in a grouped kanban
view, the quick create widget wasn't automatically re-opened, which
didn't allow the user to quickly create several records in a row
(without clicking each time on the '+').
This desired behavior had been broken by rev. 1d34e26, which aimed
to properly reload the kanban column when a record was created
(e.g. column counter, progress bar...).
Two attempts of dealing with sorting (and resequencing) in tabbed (multi-pages)
x2many editable lists (see odoo/odoo@c2563db and odoo/odoo@983c7ae) have been
previously done, using a static attribute (`keepChangesUnsorted`) on the
datapoint.
This solution sadly only covers both cases separately, not if they are combined.
Morever, onchanges were not correctly managed in neither of these two cases.
A new approach is used here, by "freezing" and "unfreezing" the datapoint when
needed, which is more flexible.
Some modifications have been introduced:
- when ordering a x2many, all records are now considered (and not only the
records on the current page) ; an additional read is thus done on the sorted
field for all records in the x2many relation
- `setSort` is now asynchronous as a `read` might be needed
Before this rev., when a graph view was reloaded (e.g. by clicking
on the graph view switcher), the inital groupby was lost if it
didn't come from the searchview (i.e. if it came from the context
or from the arch). For instance, go to Sales > Reporting > Sales
(the view is grouped by 'date', and there are two groups), reload
by clicking on the graph view switcher: there is only one group
left.
The reload RPC was actually fine. What was wrong is the 'state'
object given to the renderer after the reload, as it didn't contain
the correct groupby, so the view wasn't correctly re-rendered.
There is a drawback in 12048bd6, if a kanban view with an
"Undefined" column (exist when a kanban view grouped on a relational
field and some record have this field unset) had a column resequenced a
traceback would happen if more than one column was displayed.
This happen because before we had a "undefined" ID for the "Undefined"
column and after 12048bd6 we get a framework unique ID which was not
managed.
note: this commit also adds `left`/`right` values in the dragAndDrop
test utility function so an element can be dropped at the right/left of
another element.
related to opw-782433
closes#21708
Before this commit, the way mode was handled was not optimal. The end
result was correct (the widget were properly created/displayed in
edit/readonly as required), but useless work was done. In particular,
if we have list/x2manys with widgets and modifiers, it could happen that
widgets were created in edit mode, then destroyed and recreated in
readonly mode.
This could happen in some important views, for example, any view with a
field many2many_tags with a readonly modifiers (pretty much all views
handling taxes)
In this commit, we add a 'editable' attribute to list renderer. This is
necessary, because the list renderer is not actually editable when it is
in a x2many in a form view which is in readonly mode. Also, we need to
manage the distinction between the fact that a list view is editable,
and the fact that some widgets are created in edit and other in readonly
mode, depending on modifiers, and on which line is being edited.
We also add a benchmark (courtesy of CHM) to be able to measure the
performance impact of edit/readonly/onchange in a larger form view.
Before this commit, running this form benchmark on my machine gave a
number of 0.4 op/sec, and after, it increases to 1.26 op/sec, so a
pretty large improvement.
This rev. introduces two helper functions for the tests: patch
and unpatch. Those function allow patching an Odoo Widget (e.g.
AbstractField), and unpatch it at the end of the test with the
guarantee that the Widget's prototype is exactly the same as it
was before the test.
This was necessary because the way it was done before was a little
bit too naive, and could lead to unexpected behavior. Indeed, doing
var someFunction = AbstractField.prototype.someFunction;
// test content
AbstractField.prototype.someFunction = someFunction;
is correct if someFunction is actually define (or overriden) in
AbstractField, as in that case, it really exists on its prototype.
Otherwise, it isn't correct if it is not directly defined on the
prototype before the test, as it will be after..
If a kanban view is grouped on a many2one, records with the field unset
are displayed in a column "Undefined" displayed first.
But the tab in mobile view doesn't respect this, so we can get:
columns: Undefined colA colB
tabs: colA colB Undefined
So we always get always on the wrong column wrong when clicking on a
tab: clicking on colB we get on colA, clicking on Undefined we get on
colB, ...
note: in this commit the "false" tab has been set to a translatable
"Undefined" name.
issue found when working on #21199
A kanban column has two identifiers:
- db_id: framework unique identifier for the column
- id: either the record res_id (grouped on x2o) or the value
The issue is that sometimes the value may be a any string which
would be source of issue unexpected for an ID (and there was one
issue in mobile renderer).
This code change this so "id" is either the record res_id or
`undefined` value, and when used in XML we use id or fallback on db_id
when we need an identifier.
So in the XML data-id on a colum is always either the ID of the record
the group is based on, or the db_id in the form.
opw-782433
closes#21199
Most field widgets are synchronous, but some of them have to do extra
work before being ready (for example, the pad widget, or widget which
needs to lazy load JS/CSS files). Because of that, the new views have
been well tested with synchronous widgets, but not completely with async
widgets.
Some code depended upon the fact that the widget was ready immediately
after being created. This was incorrect, and is fixed in this commit,
by adding a new hook that is called in (basic) views after a widget is
ready (meaning, start and willstart are done)
on pricelist, open a pricelist form
click on one country group [country group form opens]
click on a pricelist again
Before this commit, a traceback appeared, saying the pricelist record was null
YET the pricelist's form on which we clicked before opened.
After this commit, the form of the pricelist opens, and no traceback is thrown.
OPW 783896
[FIX] web: test circular many2many
closes#21148
Since odoo/odoo@da136d8 the modifiers in the widget attrs are parsed.
`stringify` thus needs be to used when displaying them in the debug tooltip (to
avoid to display [Object object]).
The attribute `autocomplete` is set with the jQuery function `attr` but
the test was using the function `prop`.
This seems to work in Chrome but apparently not in Firefox.
Before this commit, the 'limit' attribtue worked properly for list views
(but was not documented), and was ignored for inline tree views. There
was no good reason for that limitation, so we fix this issue.
If the kanban view is grouped by a readonly field, it should not be possible
to drag&drop the record from one column to another as this will trigger a
write on this readonly field.
It should however be possible to resequence records so the option `containment`
is used in the records.
Closes#19390
Before this fix, when adding the attribute delete=0
on a listview, it was still possible to delete records
via the menu 'Delete' in the sidebar.
After this fix, this should not be possible to delete
records when delete=0.
The attribute delete was hard-coded to true, as there was
a traceback when it was set to false. It was simply due
to a misplaced closing brackets that was hiding an
assignment, which resulted to calling a method on undefined.
Before this fix, when adding the attribute delete=0
on a listview, it was still possible to delete records
via the menu 'Delete' in the sidebar.
After this fix, this should not be possible to delete
records when delete=0.
The attribute delete was hard-coded to true, as there was
a traceback when it was set to false. It was simply due
to a misplaced closing brackets that was hiding an
assignment, which resulted to calling a method on undefined.
Before this commit, asynchronous field widgets (with willStart async),
with a non empty template had a problem: the invisible modifier was not
applied properly.
The reason is that the code that applied the modifiers was called
directly after the widget was 'willStarted'. This means that if this is
async, and if there is a template, the $el in willStart will be replaced
by another $el after, which will remove the invisible modifier.
This was an interesting problem with the pad widget (it is asynchronous
the first time a pad widget is instantiated)
Before this commit, asynchronous field widgets (with willStart async),
with a non empty template had a problem: the invisible modifier was not
applied properly.
The reason is that the code that applied the modifiers was called
directly after the widget was 'willStarted'. This means that if this is
async, and if there is a template, the $el in willStart will be replaced
by another $el after, which will remove the invisible modifier.
This was an interesting problem with the pad widget (it is asynchronous
the first time a pad widget is instantiated)
Before this rev., sorting groups in list views wasn't supported. It
hadn't been implemented in the new views.
This rev. activates the feature, so groups can now be sorted on
their aggregates again. It also implements a basic (first level
only) sorting in mockReadGroup, in the mock server.
opw 781288
In the view dialog test suite, a few tests created a parent widget, then
created a view dialog, and destroyed the view dialog at the end, but not
the parent widget. As a result, the environment was not properly
restored at the end.
In this case, the test 'SelectCreateDialog correctly evaluates domains'
changed the session (with user_context: {uid: 2}), and this made other
tests crash (web_editor test in particular)
In the view dialog test suite, a few tests created a parent widget, then
created a view dialog, and destroyed the view dialog at the end, but not
the parent widget. As a result, the environment was not properly
restored at the end.
In this case, the test 'SelectCreateDialog correctly evaluates domains'
changed the session (with user_context: {uid: 2}), and this made other
tests crash (web_editor test in particular)
This rev. introduces a new test suite meant to test the webclient
components on mobile devices. The key 'config.device.isMobile' is
forced to true in this test suite, so that mobile specific JS files
are properly executed, which isn't the case in the classic JS test
suite (setting isMobile to true in the test definition is too late,
as the JS files are already processed).
For now, this new test suite contains a single test, which was
skipped until this rev. as it couldn't be executed in the classical
JS test suite.
Both suites are executed at each build of the runbot, and they
can be manually executed from the webclient as well (via the debug
manager).
Here is a situation where we had a problem:
- a form view with a one2many field, which has no inline views
- the (non inline) list view has a field A, and is not editable
- the (non inline) sub form view has fields A and B, with an onchange on
B which modifies A
In that case, the user could do this:
- go to edit mode
- click on 'add' a new one2many line
- change the value of B in the form view, this changes the value of A
- click on save to close the modal form view
- click on the new o2m record to reopen the modal form view
- rechange B
=> the onchange does not work
The explanation is that when we reopen the modal, we update the known fields
information, but we had to perform a fieldviewget to fetch the list
view, so we have a full knowledge of the fields. However, the code did
not update the fields info (because it uses _.default), which means that
the onchange information contained in the form view is lost.
Note: the test system had to be adapted to more closely simulate what
actually happens. In particular, the onchange flag is no longer added
by the mock server, since it should be done by the data manager, like
'real' code. This change broke the basic model tests, which had to be
modified accordingly, by setting manually the onchange flag.
Before this commit, an issue occured when you tried to
create a new record in a editable grouped list view.
A new line was created with an undefined group.
Editable grouped list views are not supported.
So now, we have to switch on the form view when
you click on create. This behavior is already implemented
when you open an existing record.
An error occurred if the domain or context applied on a view
opened in a dialog needed to be evaluated (e.g. if they contained
something like [['some_field', '=', uid]]). For instance, create
a custom filter with such a domain for the Contact model, then go
to Contact, create a new one, and on the parent_id many2one, click
on search more. Before this rev, no eval context was given so the
domains and contexts couldn't be evaluated, and it crashed.
Calendar tests did not go into US for a timezone problem, making it more difficult to correct errors.
To do: pass all the tests js in US (with simplification for the calculations of the times)
Before this commit, buttons in form view with the confirm attributes had
a peculiar behaviour:
- < saas-16: they saved the record as soon as you clicked on them, so
the warning was basically ignored
- in saas-16+ (the new views): the button did not save the record before
calling the method, at all.
This can be a problem, obviously. Also, it does not seem consistent to
have a different behaviour when the user clicks on OK in the confirm
dialog, compared to a button without the confirm attribute.
So, with this commit, we just make sure that such buttons save the
record before calling the method, just like other buttons.
1- When viewing for example journal items.
2- Now activate a filter that would display no record
Before this commit, the column aggregates of case 2 were the same as case 1.
After this commit, we recompute the aggregate, which ever case we are in.
OPW 777660
closes#20452
Aaron Bohy