The changed test uses the drag&drop helper, and an operation does not work as expected with the given params on chrome 90. The runbot currently uses chrome 80, so it is not an issue, but if your chrome is up-to-date, and you try to run the test suite, this test would fail. closes odoo/odoo#70008 X-original-commit: 43994da9980e4133274984f720bb58f3546ea0f9 Signed-off-by: Géry Debongnie (ged) <ged@openerp.com> Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
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>
Commit [1] altered the way the FieldMany2Many behaves with respect to 'create' and 'delete' options. Indeed, for many2many fields, adding or removing records doesn't mean "creating" or "deleting" records, as it is only about adding/removing records to/from a relation. This is completely fine and correct. Unfortunately, a feature has been lost in the process: it is no longer possible to state that a many2many field should be editable but should not allow to add (or remove) record to the relation. This commit fixes the issue by adding two new options: 'link' and 'unlink' for that purpose. [1] https://github.com/odoo/odoo/commit/c98579d25af01c14df4baf57fb4652f3e7469096 opw~2466213 closes odoo/odoo#67358 Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
The Many2ManyCheckboxes widget displays all values that could be in the many2many relation, with a checkbox indicating whether each value is in the relation or not. It is designed to be set on fields where the comodel contains a few records (typically, we don't want to see dozens of checkboxes in the form view). This widget shouldn't be used on many2manys with a large comodel, as we have better tools to handle them (like a tree view). We deal with extreme cases (when the widget is, by mistake, set on a field where the comodel is huge) by using the name_search limit of 100: at most 100 checkboxes are displayed. Before this commit, this extreme situation wasn't correctly handled. If there were in the relation records that weren't displayed (because they weren't inside the 100 limit), then, editing the value by (un)selecting a checkbox would automatically remove all non displayed values from the relation. This commit ensures that we keep in the relation all values that aren't displayed. Issue spotted when working on opw~2439041 closes odoo/odoo#67373 X-original-commit: fa324ef071952d749f635f878bee0fa462cfa011 Signed-off-by: Géry Debongnie (ged) <ged@openerp.com> Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, if the widget "many2many_checkboxes" was set on a field with more than 40 values in the comodel (i.e. more than 40 checkboxes displayed), (un)selecting a checkbox that wasn't in the first 40 checkboxes crashed. This was due to the default x2many limit of 40: we only created a datapoint for the first 40 values, whereas we could have up to 100 values to process (name_search server-side limit). Note that this limit of 40 had no other impact than limitating the number of records processed by the BasicModel, the maximum number of checkboxes displayed being ruled by the name_search server-side limit. This commit ensures that all values returned by the server (at most 100 when this message is written) are processed and can be edited as expected. opw~2439041 X-original-commit: be5e5bc49cb9744c26ca75dcee74caf11447f250
The color_picker widget, that can be seen for example in the track form view for event tracks, had an issue: if the user clicked on it, then pressed TAB, a traceback was displayed. The problem comes from the fact that the color picker widget inherits from FieldInput, but is not a fieldinput, so many expectations made by the FieldInput code do not hold, such as the code run when handling navigation (by TAB and such keypress). Because of that, the code in _onNavigationMove crashed, because it expected an input. Since this is a bug fix, I simply disabled the navigation in that case, so no crash happens. Sadly, this widget has still a big issue: it clearly does not work as most users would expect: pressing TAB or arrows should update the selection. But this would be a more complicated refactoring, for a bug which is clearly not critical, therefore this commit implements the simple and safe solution. Also, we disable the focus outline to minimize the wrong expectation. Seeing them kind of implied that one could update the selection with the keyboard. Note that the widget color_picker was moved from another addon to web/, without any tests nor documentation. OPW 2467369 closes odoo/odoo#67174 Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Steps:
- Install mrp
- Go to Manufacturing > Master Data > Bills of Materials
- Create a BoM
- Components:
- Add a component
- Save
- Click the component
- Close the modal window
- Click the component once more
Bug:
Traceback here:
https://github.com/odoo/odoo/blob/55a6642a9621fa9683895d5d45a015bb04c3017b/addons/web/static/src/js/views/basic/basic_view.js#L147
Error: can't convert undefined to object
Explanation:
As seen on the line just above:
https://github.com/odoo/odoo/blob/55a6642a9621fa9683895d5d45a015bb04c3017b/addons/web/static/src/js/views/basic/basic_view.js#L146
`fieldsInfo` might not have the view we are looking for.
opw:2452142
closes odoo/odoo#65805
X-original-commit: b27c0698d95cbccaa6c35a1fd3faa852a71ac2c2
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: backspac <backspac@users.noreply.github.com>
This commit partially reverts commit [1], and backports commit [2] from 14.0. Even though [1] correctly fixes the faulty scenario, there is a variation of this scenario which isn't handled. It has been fixed in 14.0 by [2], and that fix also fixes the original issue of [1]. So we keep the tests of both [1] and [2], and the fix of [2]. [1] dd97d446ee94a32089f200bb7122139d31e69873 [2] f6c06bd0b87dac11d76a3134eb61c7ef4eb59270 closes odoo/odoo#65562 X-original-commit: 63c60549ef5185f5ec61dc985f0bcc2cb82ccc89 Signed-off-by: Géry Debongnie (ged) <ged@openerp.com> Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>