| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Most operations on X2Many widget possibly propagates a field context
(name_create, name_search, ...) but the original read or read on an
onchange does not.
With this changeset, the field context is also used in these instances.
The assertions added in the added test failed with:
expected: ["world"], result: [undefined]
expected: ["world","world"], result: [undefined,undefined]
fixes #29203
opw-1914466
closes #29866
|
|
|
|
Fine-tuning of commit e7fab234201e357da52c3576ad2e8fc9ceee9359
In a one2many with more than one page with a limit of k records, add a line l.
It increments the list limit to k+1. Remove a line above (of index <= k).
It will try to load a line l' to replace it, that it will find on page 2.
However when deciding if it should read missing fields on that record, it will
scan at most u records, skipping virtual ids.
Here u is the min between the current number of lines and the list limit
without the temporary increase due to the added record.
Since there are at least two pages, u = k.
However since l is in the list at index k, then l' won't be read, and since it
was on page 2 its data hasn't been loaded.
Therefore the js would traceback when trying to evaluate it.
opw 1913361
closes odoo/odoo#29338
|
|
Use case: a x2m (ex: attribute values) displayed in a x2m (ex: attributes on
product) using different fields in different views (ex: tags in product form view
and list in product attribute form view). When opening the x2m record (in a
wizard) then going back on the form view, the tags are empty because the
`display_name` value has been lost when fetching x2m for the second time.
In this case, the list `fieldsInfo` needs to be updated with the existing
(default for tags) one so all the fields will be correctly loaded.
Task 1916891
closes odoo/odoo#29598
|
|
|
|
Recent works in the orm (see [1] for example) changed the behaviour of
the server in the case of onchanges: it tries to optimize Odoo by
sending a minimal diff to the web client in onchanges.
Concretely, this means that the web client receives commands 4 (link to)
instead of command 1 (update + record data). It also sends a minimal
diff in that case. This is a big issue for the web client, because it relied
on the knowledge of the data from the command 1 to be able to evaluate some
modifiers.
The good news is that we can mitigate the issue in one case: we do not
actually need to evaluate the modifiers in the case of a command 4
(comming from the server), because we can assume that the record is
valid. So, we simply bypass the check in that case.
Note that this should fix most of the problem, but a deeper problem
still remains: a crash can still happen when an onchange modifies a
record in a one2many (but in a different page), and we also have a
modifier which needs to be evaluated.
opw: #1904514
[1] https://github.com/odoo/odoo/pull/29086
closes odoo/odoo#29172
closes odoo/odoo#29086
|
|
|
|
Have:
- Model A with a x2m to model B
- Object A with multiple objects B in x2m (that will be sorted)
- On the list view of model A, click on a column to sort by a field
- this field shall not exist in B
- open a record A (towards form view)
Before this commit, the sorting of the x2m crashed, because the key orderedBy was propagated
Due to commit e713ed2a69af9fe97fbe2d54843adc8f1ce689aa
After this commit, it doesn't crash
OPW 1913133
closes odoo/odoo#29094
|
|
|
|
related to: #28446
On a pure list view, click on a column to sort the records by that field.
Save the filter as favorite
Reload, now apply the filter
Before this commit, there were two issues:
1. The order of the list was never propagated to search view, which couldn't save
the filter with its attribute "sort"
2. There was no mechanism to load the attribute sort from a loading Filter
After this commit, those two issues are corrected
Unfortunately, complex search view flows are not testable in v11.0
OPW 1906968
closes odoo/odoo#28766
|
|
Steps:
- open a modal form view from tree view first line and make a change
- open a modal from the second line and make a change
- open the second line back: the change were lost
In a given number of conditions (a many2one inside the form view, there
is a one2many in the form view not inside the tree view, ....) this
happened because:
- when we save the first line, we get onchange data for the second one
- this onchange data can't be applied before second line is loaded, but
it is saved so it can be applied if second line is ever opened
- when the second line is opened the saved change is applied => OK
- when the second line is opened a second time the saved change is
applied again, possibly overwriting posterious change => BAD
With this changeset, when the record with unapplied onchange is loaded
for the first time, the unapplied onchange is applied only once.
Added test without the change failed with:
- only 1 turtle for second partner (result: 0 not 1)
- second partner turtle is Michelangelo (result: "" not "Michelangelo")
opw-1846820
closes #28644
|
|
Before this rev., the following scenario didn't work:
Open manufacturing order and click on Produce button (note that
bom product should have Serial number enabled) then add quantity
in Done field in o2m and press Record Production button in wizard,
it will produce UserError and after then if you change Lot number
field in wizard's o2m then the many2one value doesn't get selected.
This occured because the renderer wasn't updated after the RPC fail
and thus still got an outdated version of the state.
The issue raised after commit: 02eef78bbd3 which was done to remove
useless rpc call, it's OK to remove rpc call but let's keep
updating renderer.
Related to task ID: #1852715
Co-authored-by: Tejas Shahu <tsh@odoo.com>
|
|
Define a x2m tree view with a default_sort including more than 1 field to order the list against
Before this commit, the second field was never used
After this commit, it is used
OPW 1909785
closes odoo/odoo#28840
|
|
|
|
When a view is loaded, it checks which fields it has to load.
In the case of a many2one, it could be the case that a context key is present in
one view and not in the other; if it happens, we should reload the data, as a
name_get result could vary.
opw 1891295
closes odoo/odoo#28298
|
|
Before this commit, when loading the data and calling the prostprocess,
the viewType was not correctly passed which could lead to broken
behaviour. For example, if one was to load a record from a list view
embedded in a form view, the viewtype passed was the list which
prevented to load the data from the form view.
OPW 1891295
closes odoo/odoo#28279
|
|
|
|
The parameter would not be correctly detected by doc extractors
closes odoo/odoo#28169
|
|
|
|
|
|
Image field widget need the __last_update field alongside them
for caching purposes, though that field should never be present explicitly
in the views
Before this commit, the dependencies of field widgets were not merged into
the model's fields definition, creating a traceback when adding an image field widget
into a x2many list
After this commit, there is no traceback and the image field works properly
closes #27545
|
|
Commit:
https://github.com/odoo/odoo/commit/818c18e55d0718286ff5bf332186a10f4d7a58ef
Updated the resequence logic in a way that was almost falser than before.
The added test however did work by coincidence, as index values were equal to
the sequence field values.
To be sure that we synchronize with what happens on the server, we do a read
after the resequence.
Additionnally, we take into account the result of the server resequence return;
if it is false, it means no resequencing happened, so we should not do a read.
opw 1867049
closes odoo/odoo#27184
|
|
|
|
The domain was instantiated without being given any evaluation context.
As a result, the uid variable was not defined,
crashing the js if present in a user-defined filter.
opw 1866852
|
|
|
|
Let x_1, ..., x_a, x_{a+1}, ..., x_{a+k}, x_{a+k+1}, ..., x_{n} be a record
sequence ordered by its 'sequence' field.
Suppose the reordering occurs between elements x_{a+k} and x_{a+1}.
If the subsequence x_1, ..., x_a is ordered, then it does not change.
This is also true of the subsequence x_{a+k+1}, ..., x_{n}.
The resquence function makes exactly this assumption, and only sends the server
the subsequence x_{a+1}, ..., x_{a+k} to update its 'sequence' field.
The update of x is done as follows: it is index + offset, where index is the
position of x in the subsequence, and offset is the 'sequence' of the first
element of the sequence (i.e. x_{a+1}.sequence).
It is easy to see that we need another hypothesis: that the sequence numbers are
unique. To show it, suppose that the sequence of x_1, ..., x_a is 0, then all
x_{a+1}, ..., x_{a+k} have sequence 1, and lastly all x_{a+k}, x_{a+k+1}, ...,
x_{n} have sequence 2. Then after the call to the server resequence, the
subsequence x_{a+1}, ..., x_{a+k} would have sequence numbers 1, 2,..., k.
Since the x_{a+k+1}, ..., x_{n} subsequence have 'sequence' value 1, this would
obviously be incorrect.
We fix the reordering of the data in the js frontend to be consistent with
what is done by the server.
Note that this is only pertinent for sequences of reordering moves, since
otherwise the data comes directly from the server.
opw 1867049
|
|
Attribute may be undefined.
|
|
|
|
|
|
multiple pages
Suppose there is a one2many field embedded in a one2many,
(say we are viewing record A with one2many field B itself with a one2many C).
Furthermore, there is a second page of the one2many field B.
If an onchange is applied on B, then the server replies with a 1 command for all
B records attached to the currently viewed object A.
This includes a list of commands [[5], [4, C_id]*] for each B record,
in particular B records that are on the second page.
Since they are on the second page, they might not have been fetched by the
frontend; in that case the corresponding C_ids are thus unknown.
As a consequence, on save the frontend sends a command 0 to create the records
for all unknown C_ids.
Since it doesn't have any value to give to the 0 command, the row creation
usually crash in the backend.
Another wrong behaviour is fixed at the same time: if the server sends an update
on the list of C ids with 4 commands.
In that case, if the record has not been prefetched, we have no way to know
if the list changed or not.
To solve this, when we receive the 4 commands by the server, we send back 4
commands.
coauthored by @aab-odoo
opw 1835936
|
|
Before this commit, there was a traceback in the following scenario:
Let's have a kanban view with groupby and a domain.
If we clear the domain then clear the groupby, there could be a crash.
This crash occurs because when we clear the groupby, it performs a `reload`,
and assumes that the datapoint contains grouped data. However, if this
computation takes some time, it is possible to overwrite the datapoint so that
there is no longer grouped data.
This commit fixes the issue by enforcing at most 1 execution of the method
`reload` active at any time. Consequently, successive reloads operations are
now much slower.
Note that it uses the single non-reentrant mutex on the basic_model to enforce
this rule, which means:
- No more concurrent `reload` and `save`.
- If an execution having the mutex in `reload` come accross the same mutex,
it is blocked forever. This is hopefully not the case at the moment,
however a reentrant mutex should be considered in the future.
|
|
|
|
|
|
Let's assume a one2many A inside a form view, such that the one2many
views (list, not editable, and form) are defined inline, and there is an
onchange on A. There is another inline one2many B editable list
displayed in the inner form view (and B isn't in the list). There are
two records on the one2many A, both of them having one record in their
one2many B. Edit the first record of A, and edit it's subrecord in B.
Click on save. This triggers an onchange on A and the onchange returns a
command 5 (DELETE_ALL), and two commands 1 (UPDATE). Now edit the second
record of A, and simply close the dialog (e.g. 'Discard'). Save the main
record: the record in one2many B of the second record of A has been duplicated.
This occured because the code in BasicModel messed up information coming
from the onchange (UPDATE command) and from the read (performed when
opening the second record), thus producing a CREATE command instead of
an UPDATE one.
This rev. ensures to properly mix the read data with the onchange
result, by transfering the changes over the list datapoint created after
the read.
opw-1836785
closes #25330
|
|
Let's assume a one2many list with two fields A and B, and an
onchange on A that sets B. Before this rev., on new records, the
onchange was only triggered if the one2many list was defined
inline.
Rev. 13c885195 was an attempt to fix the onchange issue in x2manys
with non inline views, but it only worked on existing records. This
rev. fixes the problem for both cases (existing and new records),
and thus reverts the fix of 13c885195.
The idea of this fix is to make both cases behave similarly, w.r.t.
fields and viewFields stuff in the fieldsView. In the inline case
(like in the main view case), fields and viewFields are the same.
In the non inline case, viewFields contained more information than
fields. As fields is used everywhere in BasicModel (and viewFields
is basically ignored), the fix is to set fields to viewFields.
|
|
|
|
Revision on b09f0c99
The intent of the previous commit was to no drop records in a list
on discard in the following cases:
- when they have been created from a `default_get`
- when they have been created from an `onchange` that result
from a `default_get`
Before the commit above, the kind of records that were abandoned
in those cases are stated as invalid, which happens when a record
has a required field that is empty.
The case of an `onchange` that is not involved in a `default_get`
was not considered in the fixes above. In fact, this is the intent
behaviour in most cases. However, if the items in the list are
created from such an `onchange`, we should not drop them.
This commit fixes the bug where records in a list that are created
from an `onchange` are wrongly abandoned. Here is the new logic to
abandon a record on discard in a list:
- the record that is marked as "do not abandon" should not be
abandoned;
- a record that is registered as a "not new addition" in the
list should not be dropped;
- a record that is registered as a "new addition" in the list,
and has been updated afterwards, should not be dropped;
- a record that is not new should not be dropped;
opw-806650
|
|
|
|
|
|
Have a model A with a o2m to B.
In the list have a field B > m2o > C
Also have a sequence field (widget handle) on B
Then Create a record A
Arrange yourself to have two new records B popping right away (through an onchange)
in the o2m. Their C field have to be empty
Resequence those two B lines with the handle
Before this commit, there was a traceback when trying to do an name_get on the C fields
Since both of them are empty, there is no record in the localData
Hence, no model. And also no records anyway, so no need to do a name_get
After this commit, there is no traceback, the name_get is avoided when no data is to be fetched
OPW 1853088
closes #24988
|
|
There was no consideration of the fact that the widget
rendering process could be asynchronous. This commit
fixes that situation so that render a node of type
<widget name="..."> is now possible.
|
|
|
|
|
|
Model A has a o2m to model B
Model B has a m2o parent_id on B
In A's form, add a B item,
then in the m2o, create record
Save and New
Click on the m2o
Before this commit, the python crashed on name_search.
This was because we sent the virtual ids to it
After this commit, there is no crash
OPW 1850212
closes #24948
|
|
Have a decorated (conditional on field) editable list, with a default_order.
Have more records than the pager allows.
Add an item, and hit escape to cancel addition.
Before this commit, the cancellation crashed because the first record on the other page
was trying to evaluate the decoration for its row, which is wrong in the first place.
This was because creating a record increases the limit of the list, to be able to see the record
being created.
At cancellation though, that limit was never decreased.
After this commit, the whole flow happens without problem.
OPW 1844495
closes #24682
|
|
|
|
|
|
Revision on 8ac98fc78a3794e06481b02a431bcdc386a5a6ee
The commit above does not check whether the list contains data or not.
As a result, if there are no data in the list, there is no reason to
fetch `name_gets`.
In fact, there could be a traceback because some parameters of this rpc
are computed from data in the list. So if there are no data in the list,
the parameters of the rpc are undefined. This was the case for a test
in enterprise.
|
|
Revision on https://github.com/odoo/odoo/commit/9a9da5763b38a3bce54e9c4870af0032e38cacc3
The intent of the commit above was to no abandon records in a list on
discard when these records have been created from a `default_get`.
Also, the `default_get` may also perform an `onchange` that could create
more records. The records from this `onchange` must also be included in
the "do not abandon" rule.
However, the rule was too relax, so that any following `onchanges` from
a user interaction was also considered into this rule. As a result, it was
not possible to abandon such records.
With this fix, we restrict the rule to `default_get` (already the case) and
only the `onchange` right after a `default_get`. Any record created on an
`onchange` from a user interaction after a `default_get` should be abandoned
on discard.
Representation of creating the list:
savepoint
|----------|-----------|-------||--------|------->
create default_get onchange1 onchange2
record in the list is created by default_get or onchange1
=> do not abandon on discard
record in the list is created by onchange2
=> abandon on discard
|
