[Discover] Revisit how filters should be carried over after navigating from Dashboard to Discover

[jughosta]

Currently, we have 2 ways of opening a saved search data from Dashboard:

• "Explore underlying data" which includes filters but it is visible only if user has xpack.discoverEnhanced.actions.exploreDataInContextMenu.enabled=true setting. I guess most of users don't have it.
• "Open in Discover" which is available by default but it does not include filters

Maybe we could combine their functionality and provide a single default option in the context menu for a saved search panel: open a saved search plus include all current dashboards filters (query, filters, custom time range). Or we keep both options but they should be both available by default then.

Related tickets:

• Merge discover & discover_enhanced plugins #144936
• [Discover] Show "unsaved changes" label when in unsaved state of saved search #135887

[elasticmachine]

Pinging @elastic/kibana-data-discovery (Team:DataDiscovery)

[jughosta]

cc @ninoslavmiskovic @kertal

[ninoslavmiskovic]

@jughosta we probably also need to check with the ESQL saved search table and perhaps unify those also . Cc @stratoula

[lukasolson]

Related: #72637

[kertal]

In our discussion we decided that it makes sense to keep the filters that are applied to the saved search on a dashboard additionally. So we aim to show the same documents like on the dashboard. However, the user should be indicated that in Discover the resulting state / the additional filters is not the persisted version. So when we implement this, the following issue should already be resolved: #135887

[davismcphee]

@jughosta @kertal I looked into this and put together a quick PR with a working implementation: #159361.

But after discussing with @ThomThomson, I think we should reconsider whether this is the right approach. There are two main issues identified:

1. When clicking "Open in Discover", what are we actually trying to open? Is it the results as you currently see them, or is it the saved search itself? If it's supposed to be the saved search (which would be reasonable since it's a saved search embeddable), it probably makes sense to open it exactly as it was saved rather than appending additional filters.
2. The other more concrete issue with this approach, which @ThomThomson brought up, is that if you bring the Dashboard filters over to Discover, the user may accidentally save them into the saved search without even realizing it, which is probably not something we want since it can have impact elsewhere. Resolving [Discover] Show "unsaved changes" label when in unsaved state of saved search #135887 would help the issue since there'd be an unsaved changes label, but a user could still miss this and make unintended changes to their search.

It feels like we might be mixing two different actions together here that do slightly different things:

• An "Open saved search" action that would open the saved search exactly as it was saved. Not appending additional filters would eliminate the risk of unintended changes to the saved search.
• An "Explore data in Discover" action that would function similar to the Lens embeddable one and let you explore the current results in Discover, carrying over all search state but not the saved search itself (extracting search state from the saved search). Since this action wouldn't carry the saved search over, there also wouldn't be a risk of unintended changes.

[kertal]

It feels like we might be mixing two different actions together here that do slightly different things:

• An "Open saved search" action that would open the saved search exactly as it was saved. Not appending additional filters would eliminate the risk of unintended changes to the saved search.
• An "Explore data in Discover" action that would function similar to the Lens embeddable one and let you explore the current results in Discover, carrying over all search state but not the saved search itself (extracting search state from the saved search). Since this action wouldn't carry the saved search over, there also wouldn't be a risk of unintended changes.

Yes, I do agree that there are 2 different kind of actions of the user, and therefore it sounds reasonable to have to different UI elements for these actions with a clear naming. So we shouldn't add a quick fix here.