Commit [1] recently fixed an issue with nested x2many fields and onchanges: in some cases, all field values weren't sent to the server as they should. However, there is a small issue with this fix. We didn't correctly apply the default value to option `changesOnly`: when not given, it was considered false, whereas in this particular function it should have been true. It caused an issue in the following scenario: Have a form view with an x2many field (say A) displayed as a list. In the list, there is another x2many field (say B), and (whatever its type) a field C with an onchange. When the user changes C, the onchange is performed, and we send to the server the value of all fields. In particular, in the row, we send the value for the many2one field pointing to the main record (the inverse field of the x2many relation). The value for that field is basically the whole record, containing itself field A. For field A, the value is a list of commands, and for the updated record, it is a command 1. Before this commit, in the values sent for this command, field B was the empty array, even if it wasn't empty. This issue was reproducible in account.move, on an existing record having already a line in invoice_line_ids (this is field A). In that line, tax_ids (this is field B) must have a tax which is included in the price. When changing the quantity of the product, the subtotal wasn't correctly computed. [1] https://github.com/odoo/odoo/commit/a8b43d02066b2299ac2f4b88056c37725e9ce6cd opw~2489755 closes odoo/odoo#69167 Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
One might design a custom field widget to display/interact with a one2many field. Before this commit, if this field widget triggered a field_changed event to update a related record, it crashed, because the code assumed that there was a view associated with the field. Closes #68276 opw~2468238 closes odoo/odoo#68294 Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com> Signed-off-by: Aaron Bohy (aab) <aab@odoo.com> Co-authored-by: Aaron Bohy <aab@odoo.com>
Let's assume the following situation. We have a form view with a
one2many field A displayed as a list. In the list, there is a
one2many field B. B can't be edited, its value is computed by
an onchange. By default, it contains a single record (i.e. the
first value returned by the onchange is [[5], [0, 0, {...}]]).
When another field (say C) changes, B's value is re-computed to
[[5]]. Moreover, there is an onchange on A.
In this form view, let's assume the following scenario. Create a
new record and add a line to A. In this new line, B already
contains a record. Change C. This triggers an onchange that
returns [[5]], and B is now empty. It triggers a second onchange,
on the main record (as field A changed).
Before this commit, in this second onchange, B's value wasn't sent
among the other values of the new line.
The spec says that for onchanges, we must send all data, not only
what has really changed. From that perspective, the above scenario
highlights an issue.
That issue had two root causes. First, commit [1] wrongly fixed
another issue, and as a consequence, when building what to send
for the onchange, we didn't generate the values for fields that
hadn't changed inside an x2many (for added subrecords at least).
This commit reverts the fix of [1], and fixes it differently by
only sending a command 1 (update) after a command 4 (link to)
when the record is dirty (i.e. when it has been modified). See
[1] for context and details.
Second, the code that generates the values to send to onchanges is
the same as the one that generates the values to save records
(write or create). However, when saving, we only send what has
really changed. The values are at some point processed to remove
empty command lists from the list of changes (as it means that
nothing changed). However, here we ignored the flag that stated
whether we want all field values or just what has changed. This
commit takes the flag into account before removing the field's
value.
[1] https://github.com/odoo/odoo/commit/3e3a244e1afc4d74920a6302a14fa2590e8b6648
Issue reported in task~2352524
Model: account.move
One2Many (A): account.move.lines
Nested computed One2Many (B): tax_detail_ids
Field triggering the onchange (C): tax_ids
closes odoo/odoo#67679
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Co-authored-by: Géry Debongnie <ged@odoo.com>
A previous commit (8dbd1efef899fb637acca3c318ae99cb23838b8f) fixed a part of the basicmodel that used _.each to iterate on an object with field names as keys, which does not work when a field is named "length". To fix it, I simply used a native for ... in statement. However, I missed the fact that there was a second 'return' statement in the body of the closure given to _.each, so the onchange method returned prematurely. The fix is to simply use the continue statement in that case. closes odoo/odoo#67228 Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The underscore (_) library has a bug in which the _.each method does not work with object which contains a "length" property. This is because it does look for that key and if it is a number, it will assume that it is an array with that length value. Nicely done... If that length value is set to 0, then it will just do nothing, since it thinks that it is dealing with an empty array. Note that if the value is set to an object, _.each is smart enough to notice that it cannot be an array, and will do the correct thing in this case. Usually, our _.each calls are safe, since we usually iterate on arrays, or on object with safe keys, or on object with values that cannot be a number. But there was 2 unsafe calls in basic_model, which leads to strange bugs: some code is skipped, and the form view is then confused. The motivation for this fix is the fact that onchanges are not applied at all, if there is a length field set to 0. To fix this, we can just avoid using _.each. Note to every Odoo JS developers reading this: new Odoo code should avoid using the _ and $ libraries, because we do not really need them, and we want to keep our dependencies to the strict mininum. OPW: #2465808 closes odoo/odoo#66126 closes odoo/odoo#67138 Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Let's assume the following situation: in a form view, there is a one2many field A displayed as a list (non editable). In the list, there is another one2many field B displayed with no widget (it basically displays "X records"). In A's form view, B is also displayed, but this time as a list. There is an onchange on the main form view that adds a line in A, (and simply sets B to [[5]], i.e. 'No record'). Before this commit, if the user opened the newly added sub record in A, and clicked on 'Add a line' of B, it crashed. The cause of the crash was that the wrong viewType was used to create the new (default) record in B: it used the original viewType, which was undefined (B is displayed with no widget in A's list). With this commit, we use the viewType of B that is used to edit it, in this case 'list'. In the slighlty different scenario where B is displayed with widget many2many_tags in A's list, there were no crash, but wrong fieldNames were sent to the 'default_get' RPC. As a consequence, default values for fields in B's list were potentially not loaded. opw-2422806 closes #64793 closes odoo/odoo#65157 Signed-off-by: Géry Debongnie (ged) <ged@openerp.com> Signed-off-by: Aaron Bohy (aab) <aab@odoo.com> Co-authored-by: Aaron Bohy <aab@odoo.com>
Issue - Install Sales - In Sales > Configuration > Settings -> Enable "Sale Warnings" - Go to Sales > Orders > Customers - Pick a customer/company - Go in Edit mode and go to "Internal Notes" tab - Switch "Warning on the Sales Order" from "No Message" to "Warning" and add any warning message then save - Press the "$ X Sales" smart button - Create a new Quotation - Validate the warning message - Go back to the previous menu (using the breadcrumb) or save the quotation - Create a new quotation The quotation form editor does not appear. Cause If we use the breadcrumb (or save then create), it will call the `_reload` function (instead of `load` when the form view hasn't been opened yet). In this case, creating a new record, it will call `_makeDefaultRecord` without setting `allowWarning` param to true (like it is done in the ref. commit bellow). Solution Set `allowWarning` param to true before calling `_makeDefaultRecord`. related commit : https://github.com/odoo/odoo/commit/a41db9a2cf410bb233b021651a5633180eaddf18 opw-2374857 closes odoo/odoo#62534 X-original-commit: 5c8101102f999cfac6aec7658b98e376d4ed0596 Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com> Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
Consider the following situation: - have a form view with an x2many field displayed as a list - the x2many field has a form view that contains an x2many field, which isn't in the list - for that x2many field, we can also open a form view to see/edit the related records. As the x2many field isn't in the list, when we open a subrecord, we modify the fieldsInfo to add the information about the x2many field we didn't know before. Doing so automatically applies raw changes that we might have stored earlier (from onchanges) for that field, because we couldn't apply them before knowing the type of that field. Before this commit, the function that applies the raw changes was called recursively on the dataPoint and all its children (thus on the x2many list datapoint), which produced a crash as this function is designed to work on dataPoints of type record. Actually, calling it on sub datapoints is useless, as it properly works recursively, and applies raw changes on x2many fields itself when necessary. This commit ensures that we don't call this function on list datapoints anymore. Closes #62334 OPW 2389991 closes odoo/odoo#62399 Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Commit e10fd34682a0c55568cba66eb271b3aa5bed7c1d introduced batched reference fields name_gets across groups but was also buggy as follows: Have a grouped list view showing at least 2 groups Have a reference field with different values showed in the list for each record Before this commit, the name_get of those reference fiels were fetched only for the last group After this commit, the name_get are fetched in a batched fashion (by model) for each group and display correctly closes odoo/odoo#59903 X-original-commit: bbb608a1eff638040f0fc7b951fedf1579cc15b2 Signed-off-by: Aaron Bohy (aab) <aab@odoo.com> Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
An older commit (50bf8309) had refactor part of the basic field _applyX2ManyOperations. During this refactor, the reference field was forgotten to be included in a condition that made the field no longer do the quick create behavior. The name_create function in the backend was no longer called. Adds a test for the reference field checking the call to the name_create function and fixes the problem. Task id 2322048 closes odoo/odoo#59013 X-original-commit: e7d4baa3d52dc73c9631365801fbe41a4d54e3a1 Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>