Currently, only List and Kanban view supports the action helper and
display the folder icon with the helper text.

With this commit we have also provided the action helper support for
other views. The logic for no content helper has been moved in
abstract_renderer.js so that it can be accessed by all views. This was
done mainly to give the action helper to the gantt view.

closes odoo/odoo#53902

Task: 2284779
Related: odoo/enterprise#11563
Signed-off-by: Mathieu Duckerts-Antoine <Polymorphe57@users.noreply.github.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Mohammed Shekha <msh@odoo.com>

A previous commit has paved the way for displaying sample data in the
reporting views. The present commit brings the required changes in
community to have sample data in dashboard views.

Task ID: 2282196

Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>

Previous commit introduces the sample data feature in list and
kanban views. When sample data is displayed, most parts of the
renderers can't be clicked on, to prevent the user from interacting
with sample records (e.g. to open a sample record in form view from
the list). This commit disables keyboard navigation as well, as
those sample records could still be accessed with the keyboard.

To do so, several refactorings have been done in views:
 - _giveFocus function added on controllers (so that we can hook
   on the moment where we want to focus the renderer, and prevent
   it in sample mode), it kind of replaces giveFocus of ActionMixin
   which wasn't use from the outside
 - updateRendererState -> _updateRendererState as it is private
 - _setState function added on controllers, to have a hook when we
   set a new state (already existed, but only in kanban)
 - _renderView function moved from Basic to AbstractRenderer, so
  that we have a proper hook to deactivate clickable elements in
  sample mode

Task 2232801

X-original-commit: 4482a03fe2f083f4f44fc6eb76d90ae22afbff91

Before this rev. the searchpanel could only be activated in kanban
views (and it was specified in the kanban arch). From now on, the
searchpanel can be activated in any multi record view. It's arch
is moved to the search view arch (inside the <searchpanel> tag).

Task 1985921

Co-authored-by: Aaron Bohy <aab@odoo.com>

Part of task 1896658

Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Christophe Matthieu <chm@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: David Monjoie <dmo@odoo.com>
Co-authored-by: Martin Geubelle <mge@odoo.com>
Co-authored-by: svs-odoo <svs@odoo.com>
Co-authored-by: Vincent Schippefilt <vsc@odoo.com>

This branch introduces a large-scale reorganization of the
component tree generated by the web client.  The short version is
that now, the control panel is a child of the view controller and
no longer a sibling. Graphically (and simplified), we go from
this:

                  webClient
                 /    |    \
               ...   ...  actionManager
                           /         \
                   controlPanel   viewController
                                    /       \

to this:

           	  webClient
                 /    |    \
               ...   ...  actionManager
                               |
                          viewController
                            /   |   \
          ControlPanelController
              /           \
         CPRenderer     CPModel

The motivation is that this work moves the code where it should be.
Before this commit, it was kind of weird to have code in the
controllers to render buttons outside of their root node (in
renderButtons).  Also, the action manager had to take care of
coordinating search view states between view transitions.

So, this work simplifies the code.  It also makes it easier to
extend. We see day after day that Odoo needs to take care of more
complex UI needs, and in many cases, these needs were quite
difficult to implement (we prefer spaghettis in our plates, not in
our code).  The changes in this branch should open the way to
implement these features.

For example,
- it will now be easy to add the possibility of views (for example,
  the search view or a new ControlPanel view) to add custom buttons
  (of type action or object) in the control panel.
- Another need will be to serialize/ restore the state of the
  search view across action boundaries (needed by the dashboard).
- Another example is the possibility for views to customize easily
  the presence/absence of sub menus (filters/groupbys/favorites/
  time range/...)
- Another need is an easier way for views/client action to customize
  their control panel.

This commit also contains a large rewrite of the search view (so it
is more inline with our architecture and easier to maintain).

Part of task 1893568

Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Martin Geubelle <mge@odoo.com>

Before this fix, when going on the graph view from the dashboard view (
using the fullscreen button on dashboard), the focus is on the search
input, hitting the tab key creates a crash.

This fix gives a default implementation of giveFocus to the
abstractrenderer so there is no crash.

This rev. improves the way the scroll position is restored when
coming back to a view (e.g. open a kanban view, scroll, click on a
record to open it in a form view, go back to kanban using the
breadcrumbs):

 - generalize the scroll position handling from web_enterprise to
   web to make it available in the community webclient as well
 - also restore left scroll position, not only top (especially
   useful for grouped Kanban views with a lot of columns)
 - handle the case where the scrolling area is a sub element of
   the view (e.g. the grouped Kanban view in mobile).

Task 34037

Co-authored-by: Mohammed Shekha <msh@openerp.com>
Co-authored-by: Ankit Sathvara <asa@odoo.com>

Fix a bunch of ill-documented/incomplete/incorrect method docs
Without this, the automatic doc generation does not work.

*board,crm

Before this rev., the dashboard panel (e.g. of the sales team
dashboard) wasn't displayed when there were no record to display,
whereas it should. Only the nocontent helper was displayed.

This was a bug introduced with the new view: the views' controller
was in charge to display the renderer (if there were data to
display) xor the nocontent helper. As the dashboard panel was
rendered by the renderer, it couldn't be displayed alongside the
nocontent helper.

This rev. moves this logic to the renderer. So now, the controller
always contains the renderer, which decides what to render (the
data or the nocontent helper). This way, the dashboards can display
their panel and the nocontent helper.