With the new views, the barcode mechanisms were completely broken, because the view and widget JS code was totally changed. This commit update and refactor all that code to make it work with the new design philosophy. Also, it update the coding style.
Use this.rpc instead of Model object, with web.ajax if necessary. nb: EventDispatcherMixin include now the custom_events managment instead of widget
Commit cef659783514f8935cc46a496f71063d022e8dac changed the way domains are computed but forgot to change the values representation used by the Kanban view. This commit fixes that and adds tests to make sure it does not happen again.
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
Suppose the following usecase: you scan the first product of the picking. A server onchange is then triggered. You scan the same product a second time, before the first onchange has returned. You expect that the first onchange is completely executed before running the second one. This was not the case. Moreover, some onchanges were not be able to work with the invalid state of the formview at some times, and crashed. The previous implementation was wrong because id didn't run the main barcode processing mechanism inside a Mutex. It was also wrong because it didn't correctly wait for the onchange to execute (a previous barcode onchanges or some classic ones) before setting the barcode field.
Before, the '_set_quantity_listener' function was opening a 'window.prompt' which had different comportment depending the navigator. For example, the focus was not allways on the input field, the enter key 'Cancel' the prompt or 'validate' it. So to improve the usability and the consistancy we used a dialog instead a prompt, to manage the focus and the 'Enter' key pressed when we want to set a quantity.
When we are trying to set the quantity on a mobile device, we get a traceback saying that we cannot call the 'find' function on the elements returned by '_get_records'. This '_get_records' function returns a 'Collection' when called on a tree view and an 'Array' when called on a kanban view. When we are working on a mobile device, most of the one2many are displayed as kanban. The thing is when we work with the object returned by '_get_records' we call a 'find' method on it, which is implemented by Odoo's Collection class. So when we call 'find' on an 'Array' we actually call 'Array.prototype.find' which is implemented on most desktop browser and on some mobile browser [1]. This is what caused the traceback on Chrome in Android. To fix this issue, we enforce '_get_records' to always return an 'Array' and we ensure that, when working on this 'Array', we use '_.find'. [1] https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Array/find
The quantity event handler is not correctly unbound when its action
is deleted, resulting in multiple window.prompt asking the quantity
of the products if you go mulitple times trough a view when a widget
implementing the barcode thing is used.
There seems to be a bug in the framework ("barcode_scanned" events
are registered the same way than the "keypress" one on core.bus
but they don't have suffer from the same issue).
Introduced by 5bb64d40d0b94b252c2e29e6a050ae37fbd87b0f. Before doing anything we should first ensure that the quantity keypress event targets body (and that it is a number, but that's less important). Before this we didn't do that and thus the _display_no_edit_mode_warning was given when people where just typing in the associated thread of a picking. opw-672350