-
- Downloads
[FIX] web: BasicModel: store changes in x2many as operations
Datapoints of the BasicModel store the data fetched from the server and changes done (not saved yet) by the user. For x2many fields, datapoints are of type 'list' and have a 'res_ids' key containing the ids of all records in the relation. They also have a 'data' key containing datapoints of type 'record', representing the records in the relation that have been fetched (with a limit set to 40 or 80 depending on the subview used). So basically, the length of res_ids may be different than the length of data. Before this rev., the changes in x2manys were saved under the key '_changes' as a duplication of the content of 'data', i.e. same list of datapoints of type 'record', modulo the changes done (it contained the new records added and didn't contained the removed records, whereas the 'data' remained unchanged). This didn't worked at all when there were more records than the limit in the relation. Indeed, when this happened, the commands to send to the server couldn't be generated correctly. This rev. modifies the way changes are stored in those datapoints. Now, each change is stored as an operation. An operation could be of type 'ADD', 'REMOVE', 'REMOVE_ALL' or 'UPDATE'. As before, 'data' remains unchanged and always keeps the datapoints of records that have been fetched (the ones that are currently displayed in the list or kanban subview). This way, commands can now be properly computed. This had a nice side-effect of fixing two other bugs linked to x2manys. First, when used in a context (e.g. {some_key: some_x2many_field}), the value of some_x2many_field (i.e. a list of commands) was always [] if the field was invisible="1" in the view, because it's subrecords weren't fetched, and the generated commands were based on them. Now, they are generated from the list of res_ids in the relation, so it works fine. Second, the x2many records are supposed to be sorted client-side, after being read, and after each edition. This was working in the first case, but not in the second. Now it's working even after a record edition. This rev. also correctly sets the 'parentID' and 'static' keys in datapoints. Finally, we also fixed the pager in x2manys as it was badly displayed (small less tweaks).
Showing
- addons/web/static/src/js/chrome/pager.js 1 addition, 1 deletionaddons/web/static/src/js/chrome/pager.js
- addons/web/static/src/js/fields/relational_fields.js 16 additions, 3 deletionsaddons/web/static/src/js/fields/relational_fields.js
- addons/web/static/src/js/views/basic/basic_model.js 293 additions, 154 deletionsaddons/web/static/src/js/views/basic/basic_model.js
- addons/web/static/src/less/control_panel.less 7 additions, 4 deletionsaddons/web/static/src/less/control_panel.less
- addons/web/static/tests/fields/relational_fields_tests.js 405 additions, 0 deletionsaddons/web/static/tests/fields/relational_fields_tests.js
- addons/web/static/tests/views/basic_model_tests.js 83 additions, 0 deletionsaddons/web/static/tests/views/basic_model_tests.js
- addons/web/static/tests/views/form_tests.js 13 additions, 1 deletionaddons/web/static/tests/views/form_tests.js
Loading
Please register or sign in to comment