[Meta] Input panels

[rashidkpc]

Currently the dashboard is basically an output device. Ideally we'd like to add the ability to create panels that have "controls".

Examples

• Terms drop down: Would present a select dialog of terms generated by a terms agg on a field. Selecting a field would create a hidden filter that applied to every panel on the dashboard for the have of that term in that field

• Range slider: Would run a min/max on a field, and provide a slider that allows you to select a range within that min and max, resulting in a range filter

• Geo filter: Gives you a map to select a rounding box (or circle) to create a geo filter from

• Geo filter from geo_shape field: User selects target index and geo_shape field. User also selects a field containing the shape label.

• Linking Dashboards: Give user a list of related dashboards. When clicked, the new dashboard opens with same context (time, filters, lucene queries) as starting dashboard.

[chrisdrusso]

Generic control panel widgets like this would be very handy.

[tbragin]

This might be an example of a specific use for such a control: #7436

This also seems either related or the same request: #2632

[stacey-gammon]

Input control panels might help some of the folks who want the "lock dashboard" feature, #1610.

The url used for an iframe (&embed=true) removes all panel controls, along with the search, filter and top nav bar. If we had input controls, the user would be able to grant access to that functionality by dropping them right on the dashboard, but still restrict editing or removing panels.

Also could be useful for a full screen mode.

[nreese]

Where should the saved information about controls get stored? Should they get stored as their own type like Visualizations? Or should they get stored under dashboard object?

I think it makes the most sense to store controls under the existing panelsJSON in the dashboard object. The panel object would contain type: control and a controlState object.

{
    "size_x": 6,
    "size_y": 3,
    "panelIndex": 2,
    "type": "control",
    "controlState": "{}",
    "col": 7,
    "row": 1
  }

Thoughts?

[stacey-gammon]

I like storing the type control in there, but I'm not sure about putting the controlState in there since none of the other panels store their state there. We also may regret coupling an input control to the dashboard later on - say if we wanted to re-use input controls in another app, without any dashboard context.

There are three types of state that I see:

1. What type of input control is this (geo, terms drop down, etc)
2. What settings did the dashboard creator specify for this type of input control prior to adding it to the dashboard. Ex:
   • An input control that let the user set a filter on the dashboard could have the settings field and values. Maybe for the values setting, the user could specify auto which means we'd automatically fill the input options with all unique values for that field, or perhaps the dashboard creator could limit the values shown.
   • A place to specify defaults
3. What settings did the dashboard viewer set on the input control (e.g. which is the currently selected value for the drop down).

What if we have a new type that maps to a new saved object type. This new saved object type, inputControl, can have a subType, just like visualizations store their sub type - area, pie, etc.

If we add a new saved object type for control (or inputControl if we wanted to be more specific) we could give it a subtype field to further specify which type of control it is (e.g. geoFilter, termsDropDown) along with it's state. Much like visualizations handles their sub types - area, pie, metrics, etc.

For the third type of state, I think this state should be saved in the url, but not with the dashboard, so the user can adjust some settings and share a dashboard, and it'll look the same, but every time they open that dashboard up, the input control settings will be reset back to their default settings specified by the dashboard owner.

In the back of my mind, I'm trying to think about how we will support custom visualization plugins as well as custom input controls. Maybe this is getting too into the weeds, but at some point I'd like to spend more time thinking it through. Like right now, plugins can register new vis_types, and we may want to think about whether plugins should be able to register new "input controls". Or are input controls a new visualization type?

This is all just food for thought. :)

[nreese]

After some discussion, the easiest way forward is to create some Visualization plugins that are designed with the main purpose of providing controls to manipulate Dashboard filters.

[trevan]

@nreese, would this mean that custom plugins would also be able to manipulate Dashboard filters? It would also be nice to manipulate the index pattern (switch the dashboard from one index pattern to another), or edit the root search query completely.

[nreese]

Custom plugins already exist that manipulate Dashboard filters. Checkout the slider plugin as an example.

@trevan What do you mean by switching the dashboard from one index pattern to another? The Dashboard is index pattern agnostic. Each Visualization is tied to an index pattern.

@trevan What do you mean by root search query? Are you talking about the lucene query bar? There is another community plugin that offers easy controls for manipulating this.

The idea would be to migrate the functionality of plugins like these into Kibana distribution.

[trevan]

@nreese sorry, I used the wrong terminology (though both those plugins are interesting and I'll take a look at them in more depth). I think the correct term is data sources. It would be nice to edit the actual query sent to ES for each visualization from a plugin. That would allow index-pattern switching from a custom visualization. But after re-reading this issue, that is probably a different request.

[123BLiN]

I'm sorry, it is not clear from such many issues linked - is there any functionality that is possible to use right now yet for dropdown filters?

[jeromekleinen]

@nreese : thanks for your work on the range slider.

I have noticed a potential issue, or at least for me. When setting a range filter, the query created is:

gte: min value
lt: max value

The issue is of course that I am unable to include any events where the field value equals the max value of the slider. For example, one of my fields is a percentage between 0 and 100, but using the slider I am unable to retrieve the events where my field equals 100...

Could you point me to the right file to fix this?

If needed I can open a new issue.

[nreese]

@jksecurity Please create an issue

[elasticmachine]

Pinging @elastic/kibana-app

[ThomThomson]

Closing this because the legacy Input Controls are being replaced with a new Control system where most of this functionality lives.

Additionally, a few of the requests here are related to changing chart configurations via Controls, which is not yet available, but is currently being tracked in #134706