Have a user in English, put a sale report as "favorite" (pinned to dashboard app)
Change the user's language
Before this commit, the pinned view was in English (because it was recorded that way)
After this commit, the pinned view is in the user's language.
OPW 1890664
closesodoo/odoo#27574
The view_mode attribute is automatically set to the 'action' nodes
when the action is added to the dashboard using the 'Add to
dashboard' button in the searchview. However, other dashboard views
can be written by hand (see openacademy tutorial), and in this
case, we don't want to hardcode action's params (like context or
domain), as the dashboard can directly retrieve them from the
action. Same applies for the view_type, as the first view of the
action can be used, by default.
Before this rev., the second usecase wasn't handled, and it crashed
when no view_mode was specified. This rev. also ensure that the
context and domain are correctly retrieved from the action.
Closes#24088closesodoo/odoo#27517
It is possible in a dashboard item to open a form view of a record.
The view did not take into account the action used to display the item,
so for example: from a customer invoice clicking on a record would
display the "Vendor Bill" instead of "Customer Invoice" view.
With this fix, when a view is being loaded to be displayed in the
dashboard, we save a reference to a possible form view and if the form
view is displayed, we use this reference.
opw-1865454
closes#25718
Before this commit, whenever we do an operation on any of these custom views,
such as folding it, the custom view was saved by creating a new one.
This behaviour comes from a lost feature to undo operations on custom views.
Since we do not have this feature anymore, it makes no sense to create new
custom views on save, instead of applying the changes in place.
With this commit, custom views are edited in place.
Fixes#23712
Backported fixes:
1. [IMP] web: GraphView: remove hack to render in DOM
- ref. 166319fa4a
- fully backported.
This commit backports the fix that removes the hack for rendering graphs
(delay in a setTimeout), so that the graph is rendered when it is in the DOM.
2. [IMP] web: restore scroll position
- ref. 4e204ed223
- partially backported: only keeps `on_attach_callback`
and `on_detach_callback` in the abstract_controller
and in the abstract_renderer.
This commit backports the use of the hooks methods `on_attach_callback` and
`on_detach_callback` in abstract controller and renderer, so that the
controller of any view warns the renderer when it has been attached in
(or detach from) the DOM.
Also, this commit adds `on_attach_callback` and `on_detach_callback` for the
dashboard app, so that the graph view is correctly rendered.
Fixes#24092
Before this commit, when having a kanban within a dashboard and clicking on an action button,
the action was not triggered, instead, the board form view triggered 'save' on the board model
leading to a server side traceback
After this commit, the action button triggers the demanded one and only this one.
OPW 805707
closes#22191closes#22371
After uninstalling an module, some actions specified in the dashboard
may not exist anymore (the dashboard view isn't correctly cleaned up).
This was causing a traceback because the dashboard was trying to load views
corresponding to an non-existing action.
Closes#19995
Before this commit, only the routes which began by '/web/image' were
mocked (simply ignored). This forgot the case were it is a full URL
(http://www.test.com/web/image). Now, also mock the static images
routes (for .png and .jpg).
In the dashboard, the domain wasn't passed to the view since the new views.
The action in the dashboard and the one saved were thus different (ex: when
saving 'Customer', you got all partners).
This was also causing a traceback when editing a value in the grid view.
This domain is now correctly passed.
Before this rev., the dashboard wasn't rendered correctly when
the same action (same action id) was several times in the
dashboard.
For instance, if the dashboard contained the list and kanban view
of an action, both views were rendered in the same block, leaving
the other one empty. Moreover, (un)foldeing one automatically
(un)folded the other one.
This was because the action id was used to identify each view, but
this id is not unique in the dashboard. We now use a generated id
instead, which is unique.
With the new views, we totally broke the dashboard. This commit
rewrites all the code to comply with our new coding guidelines, and make
sure it works, with some tests.
Note that a big change is that we don't instantiate an action manager
and a view manager, we directly instantiate the views.
Also, this is not the best way to organize the dashboard. I think that
it should be a client action, not a form view, so we don't have to
overload all the form view classes and we don't depend on form view
behaviour/view caches/...
Lucas Perais (lpe)