summaryrefslogtreecommitdiff
path: root/addons/mail/static/src/js/basic_view.js
AgeCommit message (Collapse)Author
2018-01-26[REF] web,*: move fvg processing from DataManager to ViewsGéry Debongnie
*: mail, web_diagram
2017-04-11[FIX] web,mail: one2many records: multiple viewsAaron Bohy
A record of the basic model may need to be displayed in different views (e.g. a o2m record is displayed in the, e.g., Kanban view inside the main form view, and if clicked, it is also displayed in the form view opened in a dialog). However, the fields present in those views may differ. The previous implementation of fieldsInfo in the record didn't handle that, as it was a dict whose keys were field names. With this commit, the fieldsInfo is dict whose keys are view types, and the values are dicts whose keys are field names (the fields of the corresponding views, with they attrs in the view). This allows to create multiple o2m records in a row in a form view.
2017-04-11[REF] web: change internal representation of fields and view meta datasChristophe Matthieu
* Data manager load_view returns a viewInfo object * ViewInfo contains: the arch, fields and fieldsInfo objects, and some extra informations * The fields come from the server and are frozen, without any view attributes (depend of the model). * The fieldsInfo contains every view attributes and informations.
2017-04-11[REF] web, mail: use field registry in views, not renderersqsm-odoo
Before this commit, the AbstractField specialization to use to instantiate a field was determined in the renderers. Now this is regrouped in BasicView. Note: renderers are still left free to not use the determined Class (like Kanban and not editable List which instantiate widgets only if the "widget" attribute is present).
2017-04-11[REF] web, *: redesign all JS viewsGéry Debongnie
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