Odoo - The current checkout of upstream Odoo

Age	Commit message (Collapse)	Author
2017-08-03	[REF] web, website: o_website_modal -> o_technical_modal	qsm-odoo
	Opening a modal in Odoo should be done thanks to the 'Dialog' class. In the frontend, there can also be modals which are meant to be shown to the unconnected frontend visitors and those should then get the style of the website (bootstrap) and not the one of odoo. To manage this, the website JS code was extending the Dialog class so that it adds the 'o_website_modal' class on modals which are opened thanks to the class. The LESS code was then in charge of forcing the Odoo style on those. This behavior is not the right one. "Visitors" modals should also be able to be opened with the Dialog class. This commit is a first step towards to the right behavior: - The standard 'Dialog' adds the 'o_technical_modal' class on its root element by default and allows to not put it thanks to 'technical' options. - 'o_website_modal' is then replaced by 'o_technical_modal'. What should be done next is: - Use the Dialog class when it is possible - Move modal.less in the common assets and make it style only technical modals -> remove some forcing of the style on 'o_technical_modal' in the frontend This behavior also allows future improvements, like building a completely different structure for technical modals which would allow better designing and the end of visitor/technical bootstrap conflicts (and so LESS efficiency).
2017-07-24	[IMP] web, *: lazy load dialog xml template	qsm-odoo
	* web_editor, web_planner, website The 'Dialog' class is used in both backend and frontend. Also, lots of actions can be done without the use of any modal. It thus makes sense to lazy load its related xml only when a first modal is opened. This change also allows to get rid of the "base_common.xml" file as the dialog template is the only remaining one in there and, in the future website update, it will allow to not load any static XML file on website page loadings.