[Dashboard] Readonly or Hidden Filter Pills

[Sjaak01]

Hi,

I would like to see x-pack enhanced with the ability to control why can see, turn on/off filters saved with a dashboard without affecting filters created by the user him/herself when clicking a visualization to drill down.

Use case example
We're monitoring a lot of equipment in Kibana. All hardware is the same thus all dashboards are the same but just with a different name. I've applied and saved a filter to each dashboard that makes sure a dashboard only loads the data for that particular device.

The downside of this is that, for example, the support team, which are dashboard only users, can still see and turn off that filter. One negative result is this will make a request to our server which is way larger than it can handle. Another one is that it might cause confusion if we give customers access as well who might not necessarily be very well versed in IT.

I want users to focus on the data and remove and as much options they don't as possible

Possible solutions

1. Add an option to make certain filters immutable based on permissions.
2. Add an option to hide certain filters based on permissions.
3. The above should not prevent a user from creating new filter by e.g. clicking a visualization inside the dashboard.

Other requests
Slightly unrelated by an addition option to hide the query bar and add filter buttons (without affecting the ability to add filters when clicking a visualization or using the controls visualization) altogether would be welcome as well.

[kobelb]

If I understand correctly, you're looking to restrict which users are able to add filters using the filter/query bar for Dashboards?

[Sjaak01]

Correct.

Mainly I would like to see an option to hide/make certain filters immutable. This shouldn't affect the ability of users to add filters when they click visualizations though.

[elasticmachine]

Pinging @elastic/kibana-app

[elasticmachine]

Pinging @elastic/kibana-security

[kobelb]

I've removed the security team label from this. This is dependent upon #35616 but the specific feature will be implemented by the app team.

[elasticmachine]

Pinging @elastic/kibana-visualizations @elastic/kibana-visualizations-external (Team:Visualizations)

[ThomThomson]

This is a very interesting request and one I've heard multiple times. I've added the Visualizations team to this because this is worth discussing and would likely include both Presentation team and the Visualizations team.

The longer term approach that I can picture is either:

1. Giving the dashboard author an option to entirely hide the unified search bar, but allowing either UI actions or drilldowns to add control selections so the viewers can interact with controls only. This is higher effort, especially considering that Controls will exist as panels on Dashboards (there could be multiple - which would be affected?).
2. Changing the filter pills to allow for required and hidden props that the dashboard author can set. In view mode, these filter pills would be required or hidden. This would be a lower effort solution, and likely more inline with user requests.

What do you think @stratoula?

[stratoula]

Thanx Devon!

1. I don't understand the first one. So the suggestion here is that interacting with a chart should not create a filter pill but create a control?
2. I like this proposal to be honest, so when I save a dashboard (as author) my filters' permissions are also saved, so if I open as a viewer I see only the filters that I can change (or the filters I can't change are there but I can't change them)

[ThomThomson]

The more I think about it, the more I realize that Option 1 is a little untenable -

Giving the dashboard author more options in terms of which filter pills are shown, hidden or readonly (Option 2) will be very powerful and not terribly difficult to implement. And yeah exactly, I imagine that the hidden / readonly state would be saved into the filter pill state. One piece of complexity is that the filter manager would need to have a setting that represents view / edit mode?

[stratoula]

So we need on the filter level a property that tracks if is hidden/readonly and somehow to indicate to the unified search the view/edit mode I guess(?)

[ThomThomson]

Yeah that sounds about right to me! And we'd likely set that view/edit mode toggle to view mode by default. That way the two extra options we add only show up in editing experiences like dashboard.

[stratoula]

Sounds good, we can figure out the details when we start implementing the feature ;)

[stratoula]

+1 https://discuss.elastic.co/t/readonly-or-hidden-filters-in-kibana-discover/328699/2

[ThomThomson]

Related to #137560

[ThomThomson]

Bumping this to loe:week because this readonly setting will need to be persisted in the Dashboard / anywhere else it is used.