This commit introduce a full redesign of all JS views. We started basically from scratch. The goal was to unify all the various views under a common framework, to make them testable, to make then usable in different conditions (in studio, or in the frontend), and to make our lives easier. Some important points are: - we introduced new coding guidelines (camelCase, 80 chars width, ...) - we have a brand new testing framework (still QUnit based) - kanban view moved to the web addon - calendar view (formerly web_calender) moved to web as well - the tree view was removed - all new code should be documented We hope that this code is the start of a new era for the Odoo web client, we want to have a high quality codebase, well documented, well tested, well designed. Work done by the framework team: mostly aab, ged, chm, dmo, qsm
In a form view, when a field onchange lead to a change on a x2many, there was two different behavior: - if the x2many had an embedded view (eg. a tree view inside a form view) the onchange would notify that it expected the x2many field in this embedded view to be changed and handled the changes correctly. - if the x2many had a default view, the onchange ORM would not be aware the x2many could be modified and would not sent the changes back causing blank or not updated x2m lines and error on save. --- Two solutions were birthed to solve the second point: => PR #10557 = solving everything With this PR the onchange in the ORM is aware of every fields in the current view (even field in a x2m in a x2m in a x2m in a form view) and if any of these are change the javascript gets back the value of the fields present in the view. This PR has currently not been merged by fear of changing too much and anyway could only be done in master. => PR #12249 = if no field for x2many, send its form view fields With this change, if the ORM onchange is not aware of the fields in the x2many widget to returns, all the field in the x2m default form view are returned. This was merged in bbdf960 but introduced a number of other issue: - in most situation the x2many is represented by a list view, which may have fields missing of the form view, so the original is still present. - the view used may differ from the default form view in other way (depending on value in context or other possibilities). - the form view could have fields not present in the form view which could end up in `write` on fields which should not be written to. --- This commit reverts bbdf960 and adapts a small part of #10557 so the x2many with default view works as an embedded x2many. For more than one level (eg. a x2many in a x2many) this would still not work but it is only solvable by a PR such as #10557 which could only be targetted for master. With this commit: - the list of fields sent to ORM onchange is computed at the first onchange - the fields from a x2many field default view is sent for onchange - the initial onchange on record creation is delayed to when x2many are loaded closes #12249, closes #15336, closes #15890 fixes #11236, fixes #12249, fixes #15129, #15419 opw-705965 opw-716095 opw-715619 opw-710440
To reproduce: - Get a slow connection, e.g. activate throttling in debug mode of the browser. - Create an invoice with at least one tax. - Change a price unit. - Click on 'Save' then repeatedly on 'Validate' The tax lines are duplicated. The issue comes from two identical `write` calls whose purpose is to delete the existing tax line and create a new tax line. The two calls are issued by the click on 'Save' and the click on 'Validate', which triggers a 'Save' since it doesn't consider the form as being saved yet. There were several issues: - The buttons from the statusbar were not disabled - The buttons were enabled too soon. They should be enabled again when the form is reloaded, otherwise the call to 'Validate' doesn't consider the form saved. This is an extension of commit https://github.com/odoo/odoo/commit/bbbf3db581b5cf883 opw-710642
Before this commit, in the form view, if an attrs domain contained the "id" field, it only worked if the "id" field was explicitely added to this form view. As the "id" is obviously known on a form view without the need to be explicitely added, this commit allow using attrs domain containing "id" in all form views. Note: this seems to already work with list views.