Dashboard Embeddability and Custom Panel Plugins

[stacey-gammon]

What
We currently support two types of dashboard panels - visualizations and saved searches. We should make this more flexible to support a wide range of displayable plugins.

Why
I created this PR to explore the idea of creating a panelRenderer registry, however after a few different chats, I don't think it's the right move to have an additional pluggable entry point when visualizations are already pluggable.

Having two different mechanisms to do this creates confusion. What should be a specialized visualization type, and what should be a new, top level type? When discussing input controls (#6884) we ran across the same question.

I propose that we move to a single plugin system. By extending the current visualization plugin system we can make it flexible enough to consume a wider variety of items.

How
We need to get rid of rendering logic inside Dashboard itself and push it into the visualization plugin system. If we can make Saved Searches a visualization plugin, then dashboard won't need this logic. In order to make this happen, the visualize plugin system needs to:

• handle querying the data directly (right now dashboard grabs the SavedObject and search source).
• Allow for an external editor (e.g. saved searches are created in discover tab, not inside the visualization tab).

Open Questions

• We either need to have a tab attribute so dashboard knows which tab in the Add panel to place the list of visualizations, or we need to do away with those tabs. Which approach is best?
• If we do away with the tabs, can we still allow a direct add link inside visualizations. e.g. we have now an Add visualization link, but an Add saved search button would just take you to discover.
• Would we want a Saved Search link inside the new visualization list? We have a Timelion in the list but it keeps the user inside the Visualize tab, instead of redirecting them to Timelion. How should we handle external editors like timelion and discover? Can we avoid having two places to edit them (like timelion does now), and avoid requiring a special way to save these before they become available to a dashboard?

[kobelb]

Would adding the concept of a "visualization category" to which these visualizations belong unify the need to have a way to distinguish which "tab" they should belong to while enabling the direct add link in each of the tabs?

[stacey-gammon]

Yea, we could do something like that, but we have to be careful with creating confusion with the groups visualizations are already in now (e.g. "time", "maps", "basic charts", "data"). I think we should probably just redesign the add panel rather than creating another way to group the types of visualizations.

I'm sure once we get there the design team will weigh in and come up with something.

[kobelb]

Good point, didn't think about the groups/categories that already exist. Disregarding the naming/specific implementation, I think this is definitely a worth-while effort.

[alexfrancoeur]

@stacey-gammon @nreese What are your thoughts on an input control that can switch between saved searches? At the moment, I believe all visualizations (with the exception of Timelion and Time Series Visual Builder) are tied directly to a single index. However, that may not always be the case with the refactoring work Peter is doing. If we were to introduce such a feature, we could address the need for scripted dashboards (#2116). Imagine switching between saved searches on a dashboard where each saved search is specific to a host or a customer.

[stacey-gammon]

Closing in favor of #19875