Courtesy of Juan José Scarafía, ADHOC
The quality of the Spanish (Argentina) translations is very poor.
Remove them all and will start from scratch, translating only when needed.
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
Rev. 69c9500e recently added option 'keepSearchView' to doAction in
the ActionManager. When set to true, the searchview of the current
action is re-used by the executed action.
This caused issues with the dashboard, as the wrong action id was
used to save the current action to the dashboard (it was the one
of the action for which the searchview was instantiated, not the
one of the current action, executed with option keepSearchView set
to true). For instance, go to Website (in enterprise), in the
new dashboard (view) expand the graph view, try to add the graph
action to the dashboard (board).
Task 1835670.
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
Recently, rev. 5b3cb812b added a new custom event ('update_filters')
handler to the ActionManager, and rev. 69c9500 added an option
('keepSearchView') to doAction (which can be called by triggering
up event 'do_action').
Both events ('update_filters' and 'do_action') can be triggered by
controllers, and when those controllers were in the dashboard, a
crash occured when they triggered those events. In particular, they
are triggered by the new 'web_dashboard' view, respectively when
clicking on an aggregate and when clicking on the subview button to
open it full screen.
The crashes occurred because the events weren't intercepted by the
dashboard, so they bubbled up to the ActionManager which couldn't
handle the requests properly as it wasn't aware of those sub
controllers.
As there is no search view in the dashboard, the 'update_filters'
event simply needs to be stopped (we can't handle such a request
in the dashboard), and for the 'do_action' event, the
'keepSearchView' option must be forced to false as there is no
search view to keep (we thus force the ActionManager to create a
new one).
Instead, create a new BoardView (in JS only) instead, referenced by
specifying js_class="board" on the fly on the root node of the
arch of the board view.
This ensures that the dashboard addon doesn't impact the FormView,
and this is necessary to ensure that the next commit doesn't break
anything.
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
Christophe Simonis