This commit ameliorates the tooltips and the legend
of the graph view in its different modes (bar, line, and pie).
Related task id: 1917940
Co-authored-by: Mohammed Shekha <msh@openerp.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
closesodoo/odoo#29747
Before this rev., the pie_chart widget was rendered from scratch
with nv.d3 and we had duplicated code.
In comparison mode, two widgets were instancied and it was a bit
difficult to synchronize the size of these svg graphs.
nv.d3 graphs are attached when the dom is ready because it needs
to calculate the available space. UI bugs can appear if the dom
changes... .update() must be executed on the graph to avoid this
as we already do in graph renderer.
So now, the rendering of the pie_chart widget is done by the
graph renderer.
As comparaison mode is supported by the rendering, only one
widget needs to be instancied.
Task ID: 1835644
The navbar in community now looks more like the navbar in enterprise.
Here is a sum-up of the changes in community:
- The navbar in community is now in blue, instead of black.
- No more app list that almost fills the whole navbar: there is
now an "Apps Menu" in the left-most side of the navbar.
- No more sidebar for the menus inside an app: those menus are
now located in the middle part of the navbar.
The navbar in community does not support mobile (< 768px width),
but it should still somewhat usable on most mobile devices.
As for the website navbar, it has been unchanged and should still
support mobile layout.
Task-ID 1878649
Before this rev. one could set the report layout on the company using a
hardcoded list (background, clean, standard, etc.). Other modules (typically
accounting modules) could add options in this list. The used template was built
on the layout key.
Now, the layout is a many2one field to a newly created model `report.layout`,
which is linked to a view with the layout architecture.
This gives more control to customize reports and create a new layout (without
creating a python module that extend the layout selection).
* 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.
