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
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
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
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
When fetching x2manys in a x2many, the basic model did not properly sort
the internal data structure before fetching the data. This is usually
not an issue, except when we have an order which is different from the
order of the res_ids. In that case, it can cause crash in some
conditions, because the results from the fetchx2manybatched were applied
to the wrong datapoint.
To reproduce this issue, some specific conditions needs to be met. I
think that it is easier to refer to the test, instead of trying to
explain that.
In this commit, we properly sort the data at the correct place. Note
that this probably solves a bunch of other related issues, caused by the
fact that the internal structure was corrupted.
Cleaning dead code from these commits that have been reverted:
41fe7f9d1113d026b226b136b4477aaaf9f1f638#diff-54fd886cc58f994ad518ee72df4d3edeR50
2a5488619da22cfd901963dd141e722b195e82ab#diff-f96b339a9374f74489f1f98755e9787bL9253
41fe7f9d1113d026b226b136b4477aaaf9f1f638#diff-86d6d41b5bb7499bf055258d05549d59R3111
With these final changes, we hope to stop the many issues that have occured with
binary fields, from these commits:
255e8ca3d97813a8e71441fe7f9d112a5488619d
What remains is the format of binary fields in list views without widgets,
which shows the bin_size instead of the base64 string representation...
... Rest assured, the computation is in JS, so there are no 'bin_size'
shenaningans!
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.
Revert partially 255e8ca3d9
Removed widget 'download_link', as it was a sub-version of widget 'binary':
it did the exact same thing (representation of binary fields by means of a download link)
in a much better-looking way (download icon + filename as text of the download link,
instead of just a download link with text "Download").
Also, the values of binary fields might be already a human-readable binsize (e.g. 2.52 MBs),
instead of its plain textual string representation in base64:
The contextual parameter 'bin_size', when set to true, does not download the data of binary fields.
As a consequence, the server provides the sizes of the binary, instead of their value.
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...).
When we have a form view with a one2many with an onchange, and with
lines which contains a x2many, and more lines that the limit (so more
than one page), and the read is not in the same order as what is
displayed because we have a widget=handle, then we might have a problem
when we delete one of the lines, if the onchanges tries to change the
x2many.
This is due to the fact that the order of the basicmodel datapoint is
not preserved by the various operations going around. I think that we
may still have a few other issues of this type, but it is actually quite
difficult to establish.
In any case, this situation is now properly handled.
opw 804530
Binary fields were simply shown simply by their textual representation in list views,
e.g. the base64 string.
There was no formatter for binary fields, therefore it has been implemented so that
it displays its estimated size.
Binary fields in list views had a download link in v10.0.
We provide this feature back by means of a widget called 'download_link'.
It is also possible to define an option to set the field name having the filename as its value.
Example:
<tree>
<field name="fname"/>
<field name="datas" widget="download_link" options="{'filename': 'fname'}"/>
</tree>
with the following record: {fname: 'document.txt', datas: 'Cg=='},
we get a file named "document.txt" by clicking on the download link.
Closes#21996
Issue: create 60 lines in ordered x2many with the same value (0) for the order
field and make a change ; the displayed records will be switched.
The problem appears because the sorting function is not stable and the
records with the same values can change place (hence change page), which is
quite disturbing for the user.
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
In many cases, we allow class and style attributes in the arch of a
view. However, it did not work in a list view, and there is not really
a good reason for that (only cost is a few runtime checks).
So, with this commit, we allow those attributes in list views (and
x2manys obviously).
However, note that there is a subtle (maybe slightly confusing)
behavior: when a list renderer is in 'readonly' mode, it does not
actually instantiate any field widgets. In that case, it optimizes the
rendering by putting only the formatted value inside a cell:
<td>some value</td>
So, in that case, the only valid target for the attributes is the td:
<td class="hello">some value</td>
But when we are in edit mode, we actually have a field widget inside a
td:
<td><input>some value</input></td>
And in that case, the natural home for the attributes is the field
widget. This is quite important, because this is the way attributes are
done in the form view, and we do not want different behaviour.
<td><input class="hello">some value</input></td>
In v10, a `Float` field with `widget="monetary"` option uses the decimal
precision of the field. In v11, however, it uses the decimal precision
of the currency. However, in many cases `widget="monetary"` is used in
the sole purpose of displaying the currency symbol. The precision of the
field sould be kept.
This commit introduces the support of the decimal precision of the field
for this specific use case thanks to the `field_digits` option:
```
<field name="pouet" widget="monetary" options="{'field_digits': True}" />
```
If such an option is used, the field precision will prevail over the
currency precision.
Related to #21686
opw-800279
[FIX] web: Fix column_invisible issue
This commit fixes an issue with the column_invisible attribute.
When we choose product variant for BOM for any particular product,
at that time from the BOM Lines column "Apply on Variants" is hidden,
but when we unset product variant from BOM Form,
at that time the column 'Variants" set to visible. but in this case, it is set to hidden always.
PR 21693, OPW 779555
- Set the currency rounding to 0.001 (3 digits)
- Create an account move
- Add an account move line, set an account
When switching from edit/read-only mode, the rounding switches from 2 to
3 digits.
This is because, in edit mode, the format method is the method of the
float widget. Therefore, in this case, the formatting doesn't take into
account the currency rounding.
To avoid this, we simply use a `noSymbol` flag to avoid adding the
currency symbol, while keeping the monetary rounding.
opw-800279
If a row is being edited, this row will be refocused when performing changes
(i.e. resequencing records). It can cause an issue if an onchange modifies the
record being focused.
To avoid this issue, the row is unselected before resequencing records. The row
isn't selected anymore but this behaviour wasn't expected anyway.
Resequencing records with the same sequence wasn't correctly working in the
editable list because we only care about the range between the swapped ids. In
some cases, this isn't good enough.
For example, if we have the records 1,2,3 with sequence field = 10,10,10, then,
swapping records 1 and 2 should lead to resequencing 3 with the sequence values
11,10,12 (to guarantee that the third item is after the previous 2).
Resequence now checks if the list increases or decreases without interruption
to create the subset that must be changed ; otherwise the whole list is changed.
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
The 'main_flow_tour' noticed an error that we
had already corrected for the input fields.
See here: @a71f2237
In fact the same error can occur in the many2one fields
for the exact same reason.
It's why the 'main_flow_tour' crashed at the following step:
".ui-menu-item > a:contains('the_flow.customer')"
Before this commit M2Mtags widget did not translate.
This was because no context was given to the rpc that fetched the fields
Hence, the lang was not passed.
After this commit, M2Mtags translate well
OPW 784396
When fetching batched namegets (typically after a default_get), we need
to evaluate the context that we send to the server. This may be
important for models with a custom name_get method. (note: overriding
namegets should be avoided if possible)
With the new views refactoring, this was not done properly and the
'view' context was sent instead. This is not really critical, the proof
is that it took a few months before getting some complaints, but this is
definitely a bug.
To reproduce, simply add a context attribute to a m2o field in a form
view, with a non empty value in a default get, and look at the context
sent to the server.
Let's have:
- on res.company a binary file field named x_file
- on res.users a related binary field to company_id.x_file, and make it readonly
- On the res.users form view, display the new field
Before this commit in create mode, upon clicking on download the file, the server crashed, because the record id was empty.
Then, the JS crashed in turn because of the unhandled 404 from the server.
Since the id of a new record will always be unset, we choose to disable the download option in this very specific case
OPW 777042
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)
Example of failing request:
```
rpc.query({
model: 'link.tracker.click',
method: 'read_group',
args: [[links_domain, ['create_date', '>', interval]], ['country_id']],
kwargs: {groupby:'country_id'},
});
```
The RPC request built contains the following:
```
args: [[["link_id", "=", 1]], ["create_date"]]
kwargs: {groupby: "create_date:day", domain: [], fields: []}
```
This will be interpreted server side as:
```
model.read_group([['link_id', '=', 1]], ['create_date'], groupby=['create_date:day'], domain=[], fields=[])
```
2 arguments match `domain` and `fields`, which causes a crash.
opw-781300
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]).
Martin Geubelle