Options List Control Ignores Filters and Queries

The Controls visualization has now been available for quite some time, but it is still being noted as a technical preview. Is there any plan to move this to GA? Since it was first introduced, it seems the Options List control completely ignores any filters or queries applied to it. It would be nice to see this visualization work as expected.

Thank you,
Eric

Hi @MakoWish! We have actually created and released a new Controls system which is GA and works correctly within the context of the Dashboard, responding to its filters, queries, and time range. These are available in 8.3, and you can take a look at the documentation here

1 Like

Hi @devon.thomson ,

We just upgraded to 8.3.2 yesterday, and quite honestly, this is even worse. I don't see a way to move the control anywhere, as it is pinned to the top of the dashboard. There is also no way to save a filter to this control that I can see. Most of our dashboards are based on saved queries for very specific views, and I see no way to either link the control to the saved query, or explicitly add the same filters to the control. Am I missing something? I want to filter the dashboard by what is selected from the control, not the other way around, and I only want the control to show the options based on the data driving the dashboard.

For example, we have thousands of devices running Metricbeat, but only a handful using the MSSQL module for Metricbeat. I have a saved query for event.module: "mssql", and the dashboard is driven off of that saved query. This presents MSSQL data for only that small handful of devices using the MSSQL module. Now, when I add a control to filter by host.name, the control pulls from all 3000+ devices that have Metricbeat installed. We only want to pull from the few devices that have the MSSQL module enabled.

Thank you,
Eric

Hi @MakoWish,

Firstly, RE the Controls existing only at the top of the dashboard, this is true for now. We are planning on adding a second layout option which lists the Controls vertically on the left side of the dashboard, but we aren't planning to allow authors to place the controls anywhere on the dashboard quite yet.

Regarding filtering the control - the search for controls is laid out in a hierarchy where the Query, Time range and Filters apply to the Controls, and selections from the controls apply to the dashboard. We will be adding the ability to add hidden filtering to an individual control through the control editor, but for now, you'd have to add a filter pill, a query, or a control to the left with the selection you'd like to filter subsequent controls by.

In your example, you could accomplish this by adding a filter pill to the top of the dashboard that says event.module is "mssql". This would filter the controls underneath to show only host names that are associated with mssql. Here is an example of how this works on our demo data. The Country pill filters the city control to only show cities in Canada.

You can also use the chaining feature of Controls to do this.

@devon.thomson ,

Adding a filter to the top of the dashboard is not a great idea, because if an end user clears all the filters they have added while digging into the data, it will also clear the filter that was saved to the dashboard (this happens all the time, and is why I stopped doing it). This effectively breaks the purpose of the dashboard being designed around a saved search and would once again show unwanted data. If a user does clear that filter that was saved to the dashboard, there is no easy way to get it back aside from closing the browser and navigating back to the dashboard. If there was a way to permanently save a filter to the top, that would work, but that does not exist.

As for the positioning of the controls... there needs to be a way to place it anywhere on the dashboard just as you could with the deprecated controls. Only having the option of top or left breaks the standardized layouts we have throughout our environment. The controls that are being deprecated are IMO much better than the new ones introduced, but the fact the back-end filters do not work on those controls makes them completely useless. In my opinion, the controls that are being deprecated should just be fixed and released as GA, because the intended design is exactly what we are looking for. This new design is terrible.

Eric

No update on this? I would much rather the existing Controls be fixed. These new controls really do not work.

Use case is any subset of data from any index, but taking just Metricbeat's MSSQL module for example: We have 400+ devices with Metricbeat, but only 5 with the MSSQL module enabled. If I want a dashboard for just MSSQL data, and I want a control to select by host.name, that control will encompass all 400+ devices instead of just the 5 with event.dataset: mssql, really rendering the control useless.

Eric

Still looking for a solution to this.

Hi @MakoWish, we created an issue to filter controls' values and we will work on it in the near future [Controls] Individually Pre-Filter Available Results · Issue #140112 · elastic/kibana · GitHub. The workaround until this is ready is to use the search query bar or the global filters as Devon pointed out. One clarification question, do you need to filter ONLY the control values or the whole dashboard? Regarding your other request, unfortunately, we will not add the ability to place controls anywhere in the dashboard in the short term since this is a bigger change for us.