[Dashboard Usability] Edit for panel-level filters

[Heenawter]

Describe the feature:

Expanding on #136655, we should allow users to edit their panel-level filters from this new modal since it is currently read-only. This should probably only be accessible if the user is in edit mode - if the user is in view mode, they should still see the read-only filter pills in this modal.

Describe a specific use case for the feature:

It will make the handling of panel-level filters much easier, since users will no longer have to navigate between apps to edit them.

[elasticmachine]

Pinging @elastic/kibana-presentation (Team:Presentation)

[nickpeihl]

Merging this comment from @ThomThomson from #148931 here since both issues essentially cover the same idea.

After #146314 is completed, we will have the opportunity to move more settings and panels into a centralized panel settings pane.

Should be done alongside #137206

Current State

Panel level filters currently reside in their own popover, and they can be difficult to understand due to the small size of the popover. Additionally, if we were to implement edit functionality in them, we would need more space.
What can we change?

Inside the panel settings flyout, a new query section can expose an editable (in edit mode) or readonly (in view mode) unified search bar equivalent that allows filters, query, and time range to be edited in one place on a per-panel basis.

[nickpeihl]

Changing the Custom time range per panel in Edit mode allows the change to be persisted in the dashboard saved object for all other users. Currently, users in View Mode on a dashboard can modify the Custom time range per panel in the Panel settings flyout. This change is only persisted for that user's session.

Should we also allow users in View mode to add or remove per panel filters on the dashboard? Like the Custom time range, this would only be persisted for the user's session.

Or should per panel filters only be allowed in Edit mode? In View mode, users would only be able to see the filters applied to the panel, but not add or remove filters.

[ThomThomson]

One extra bit of complexity regarding allowing changes to panel the time range / filters in view mode - right now any changes made in view mode will trigger an immediate unsaved changes badge if the user subsequently navigates to edit mode. This can cause some confusion because it's easy to miss what has changed. If we allow users to make edits to the filters / time range of any panel while in view mode we could make this worse.

[andreadelrio]

I looked at the data from Fullstory, Dashboard users in the last 90 days (paid customers). I used the data-test-sub embeddablePanelBadge-CUSTOM_TIME_RANGE_BADGE. I found a usage of 0%.

To make sure this number is right, we also looked into embeddablePanelNotification-ACTION_LIBRARY_NOTIFICATION which shows a usage of around 1%.

[ThomThomson]

To me, these stats mean we can move ahead with making the time range read only in view mode asap, so that when we add filter editing capabilities to edit and view mode it is consistent.

Further, this might actually bode well for removing those badges and notifications altogether when we move to hover actions.

[nickpeihl]

I've been researching this feature more and feel that per panel filters (including time range) should be available in View mode on a dashboard.

When considering this change, I think it helps to consider a user story ¹.

Charlie is a new entry-level analyst at a company using Kibana. He's ambitious and wants to make a good impression. One of Charlie's first tasks at the company is learning and understanding an auditing dashboard. Two of the panels on the dashboard are identical except one has a custom time range for the past 7 days while the other uses the global time setting of one day.

While analyzing this dashboard, Charlie begins to find a suspicious pattern. He needs to look further back than the previous one day, so he changes the global time picker to the previous seven days. So now, the two nearly identical panels are 100% identical. Charlie only has read access to this dashboard, so he can't change the custom time range on the panel without edit access.

Charlie determines that Carol, a senior analyst Charlie has never met, created the dashboard and goes to ask her to help. Charlie knocks on the door but finds Carol's office empty. Charlie wonders if Carol is on PTO and now how is he going to be able to conduct his analysis? Frustrated and stressed out, Charlie bumps into Barney, a senior IT technician, in the hallway. Charlie explains the situation to Barney who (perhaps unwisely) decides the easiest solution is to grant Charlie the same permissions as Carol to edit Dashboards in Kibana.

Charlie now uses Carol's dashboard in Edit mode adding custom time ranges and filters to specific panels to conduct his analysis. Some time later, Mac, another entry level analyst, comes to see Charlie to tell him about recent murmurs of confusion among other analysts at the company. Charlie interrupts Mac to show him the results of his investigation on Carol's dashboard. Charlie mentions how he tried to find Carol but her office is empty (and wonders aloud if Carol even exists???). Charlie tells Mac that Barney (who Mac has never seen) gave Charlie edit permissions on the dashboard. And Charlie reveals how his investigation keeps turning up a single suspicious user name "PEPE SILVIA".

Mac interrupts and explains that Charlie inadvertently saved the changes to the panel filters he made to Carol's dashboard. And a number of other analysts also use that dashboard and are thoroughly confused and finding it difficult to do their jobs.

I'd like to highlight a few takeaways from this story

1. There is a lot of value in ad-hoc investigations and sometimes analysts shouldn't need to edit a dashboard to conduct investigations. We allow global filters and global time pickers on Dashboards in View mode. I think we should allow per panel filters in View mode as well.
2. A dashboard may be authored with a specific time range in mind. So an author might set a custom time range on a panel to coordinate with the saved global time range on a dashboard. But an analyst using that dashboard may need to select a different set of time ranges. We made a conscious decision to allow custom time ranges for panels in View mode and I'm very hesitant to take that away and call it a feature.
3. We could make the argument that power user analysts who need to conduct investigations should have permissions to create their own dashboards. But I don't think we can stop these users from inadvertently overwriting or deleting dashboards used by other analysts.

Footnotes

1. https://www.youtube.com/watch?v=1NBfZcNU4O0 ↩

[nickpeihl]

One extra bit of complexity regarding allowing changes to panel the time range / filters in view mode - right now any changes made in view mode will trigger an immediate unsaved changes badge if the user subsequently navigates to edit mode. This can cause some confusion because it's easy to miss what has changed. If we allow users to make edits to the filters / time range of any panel while in view mode we could make this worse.

To me this seems like a benefit to users. Like if an author was exploring a potential change in View mode, they might decide they want to persist that change when they shift to editing.

[ThomThomson]

@nickpeihl you make a very good point that some analysts would be confused and annoyed with the inability to edit / remove filters & queries for individual panels while in view mode.

There is a bit of a push & pull right now in regards to analyst freedom vs author customizability. Authors want to make the dashboard as out-of-the box as possible, limiting Analyst freedom to pre-defined interaction points, and Analysts want to be able to change as much as possible without having edit capabilities.

I wonder if the solution is to allow the Authors to choose which specific filter pills are read only. This could apply to both the unified search bar at the top of the dashboard, and the unified search bar for each panel.

If so, we could make the filters / query / time Range editable in both view and edit mode, then once the read-only filter pill PR is merged, we can trust that authors will lock down any filter pills they don't want view-only users to edit or remove.

Do you think that approach would work?

[nickpeihl]

I wonder if the solution is to allow the Authors to choose which specific filter pills are #26310. This could apply to both the unified search bar at the top of the dashboard, and the unified search bar for each panel.

If so, we could make the filters / query / time Range editable in both view and edit mode, then once the read-only filter pill PR is merged, we can trust that authors will lock down any filter pills they don't want view-only users to edit or remove.

Do you think that approach would work?

I was thinking about that exact idea this morning. I agree this would be the ideal solution.

[teresaalvarezsoler]

Related #179820

[teresaalvarezsoler]

We agreed this is a decision that will fall under the Visualizations team (see discussion here) so I'm closing this issue from our board.