"Show underlying data" should pick up visualization & saved search filters

[flash1293]

When using the "show underlying data" context action on the dashboard, the filters saved with the visualization are not applied to the resulting discover view. As a user I would expect this action to apply all the filters which are in effect on the dashboard as well.

Steps to reproduce:

• Create a visualization with a filter pill (fieldA: 1)
• Save the visualization
• Put the visualization on a dashboard
• The visualization will only show data matching fieldA: 1
• Use the "show underlying data" action
• Discover should have fieldA: 1 filter pill

This would probably require us to extend the embeddable output with the local filters - at least Visualize visualization types and Lens can provide this information.

cc @streamich

Related: same for saved search #82615

[elasticmachine]

Pinging @elastic/kibana-app-arch (Team:AppArch)

[streamich]

This actually happens because visualization filters are not passed to embeddable from visState in visualize_embeddable, so tagging KibanaApp team here. Once they are passed "Explore underlying data" will automatically pass them through to Discover app.

[streamich]

A fix could be something as follows: #73023

But for it to work I needed to comment two lines in Embeddable class.

[streamich]

Also we are planning on per-panel filters feature (same as per-panel time range), we should think about this issue in a broader context. And I think we should display visualization filters inside dashboard panels. Also, would be nice if data plugin provided React components to render filters.

TODO:

• Visualize embeddable should pass visState filters to embeddable.
• Embeddable class should not reset embeddable input in constructor.
• Panel filters should be displayed inside the panels so users can see them.
• data plugin should provide React components to render a filter list.
• Filter interface could be improved to not contain global filter specific properties (like "pinned"), so it could be used in dashboard panels.
• It should all also nicely integrate with the upcoming per-panel filters feature.

[streamich]

After discussing this with @ppisljar we decided to park this issue for now and possibly come back to it later.

[ghost]

From an UX perspective, I think it doesn't make any sense to keep the button until this feature is ready.

I could see it first-hand while migrating from another software. All of our dispatchers complained that the visualization button only carries the dashboard search and filters to Discover, and not the visualization specific ones. They considered the button useless and misleading.

So it would make more sense to have only one button for the entire dashboard until the visualization-specific one is fully functional. And I really hope that this will happen soon as we are forced to load the saved search in Kibana every time we want to investigate an issue that we found in a visualization. It's a pain and it's slow.

[Rickvanderwaal]

After discussing this with @ppisljar we decided to park this issue for now and possibly come back to it later.

Is there any planning for this feature ? When can we expect this needful feature ?

[ppisljar]

no short term plan for this as there is no clear way of implementing this in a correct way. visualization could be powered by any data and at the moment we can't clearly identify the set of documents underlying it.

[archon810]

Just found this ticket after also being stumped by one our dashboards' "Explore underlying data" links just load all of the index data when clicked and lose all filters and search terms. From the UX pov, this is completely broken and confusing.

[timroes]

cc @ThomThomson I think we talked in the context of visualizations embedded in dashboards, that it would make sense pulling the "visualization" filter into the embeddable input layer, i.e. they are not attached to the "saved object" of the visualization, but to the panel information (and thus once we'd implement panel individual filters, they are the same as the ones on the visualization).

I think this issue is another good example why we might want to do this. If we'd pull up the filters/queries into the embeddable layer, we would actually have knowledge in the action about them, and could forward them to discover (at least for all those panels that used them on the panel level and not somewhere within the saved object).

[rayafratkina]

@VijayDoshi @timductive this bug results in an incredibly annoying user experience. Much of the time 'show underlying data' function is useless. I think we should consider removing it until we are able to implement this functionality reliably.

[ppisljar]

@timroes above assumes we would know how to pull filters out and i think that might be quite hard on a general embeddable level. it would already be hard with visualize_embeddable (vega could have filters in the script right ? expression can have a filter anywhere inside it)

[VijayDoshi]

@rayafratkina Agreed - if we aren't filtering the view in Discover it's not useful.

[rayafratkina]

@ppisljar my understanding is the same as yours: that it's not an easy problem. That's why I propose removing the feature until we can do it properly. As it is now, it's frustrating to the user

[flash1293]

What about removing this action from the context menu for all cases where we don’t have a good way to obtain filters (tsvb, timelion, maps, vega), but keep it for the panels where we have the means to do so (regular Visualize and Lens)? To me this seems like a feature with clear boundaries - like the “Inspect” button, it doesn’t work for TSVB and Timelion, but it’s just not shown for them so it’s clear to the user what’s happening.

[rayafratkina]

It does not seem to be as straightforward - if visualization is based on a saved search, the link does not work either. If we can fix #82615, it would make sense to keep the action for situations where it works.

[flash1293]

Good call, saved searches should work as well. If this approach (working with saved searches and only shown if there is a way to extract filters) is too much effort for 7.13, IMHO it would be best to put it behind a config flag disabled by default until we can sort it out.

[thoma01]

Been doing some development with Kibana, and came across this UX issue as well (I am currently using an older version). I think this is something that would add a lot of value for the user experience.

In addition, if a visualization is based off of a saved search and not just an index-pattern, then the saved search should be loaded as well when "Exploring underlying data".

[ishan139]

@flash1293 Is there any update on this issue? I am still facing the same with 7.15 version.

[flash1293]

This will be possible for Lens visualizations in 8.2 via #127355

[flash1293]

Closed by #127355