[Dashboard] Pinned filters are lost when navigating to dashboard through URL

[Heenawter]

Kibana version: 8.2

Steps to reproduce:

1. Get the permalink to a dashboard via the Share menu - either by snapshot or saved object, the bug happens for both.
2. Create a new dashboard
3. Add a pinned filter to the new dashboard
4. Create a markdown visualization that links to that permalink from step 1
5. Click on that link
6. Notice how the pinned filters are gone 🔥

Expected behaviour:

Pinned filters should persist when navigating to another dashboard via URL, especially if we plan to make pinning the filters the new default behaviour.

Video:

Screen.Recording.2022-08-25.at.11.10.04.AM.mov

[elasticmachine]

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

[ThomThomson]

@Heenawter Thank you for bringing this up, because it has caused problems in the past and will continue to do so until it's resolved.

It's important to note that while using Markdown links like this is common, it isn't exactly well supported. Users can work around this issue by removing the _g state from the generated snapshot link, and when I've encountered this issue in SDHs and Discuss posts, I usually recommend removing the _g state and removing all pieces of the URL before the #.

Okay, so what is causing this:

• When a filter is pinned it is moved from app state into global state. Global state is currently set in the URL as the _g variable.
• When a user clicks share, they receive a link which mirrors the state at the exact moment they clicked share. This includes the lack of global filters. This link also is fully qualified, and contains the Kibana URL.
• When they add this link into a markdown, then click on it it loads Kibana again from scratch. The dashboard loads the _g state which is set to contain no filters, and overwrites any pinned filters with the filters form the URL.

How can we fix it?
We have two methods to fix this:

1. Reprioritise / wait for The navigation embeddable to be completed. The navigation embeddable will replace using markdown in this way, and will retain pinned filters.
2. Re-build our share modal to provide more / better options for users to share dashboard links with different portions of the dashboard state.

[teresaalvarezsoler]

@ThomThomson thank you for the explanation. I'm afraid even if we do 1 we will still get this issue in the future since some users will still use Markdown. Number 2 seems to overcomplicate the sharing feature, adding another option will add cognitive load and complexity for users. Isn't there a 3rd way of fixing it just by overwriting the original global state with the pinned filters?

[ThomThomson]

As far as I'm aware, the snapshot share is mostly used to show someone else the exact view that you have on a dashboard, including all filters, pinned or unpinned. If we make pinned filters on the destination always overwrite the pinned filters that are present in the URL being opened it would break that behaviour.

@cqliu1 , @Heenawter and I are discussing an approach where we can replace the snapshot and saved object share types with one checkbox that would say something include unsaved changes. This should allow for all of the behaviours we want, while reducing the cognitive load of the share modal to just one checkbox rather than two radio buttons.

In short, we will include pieces of state in the URL only if they have changed since the last time the dashboard was saved. That includes pinned filters - if no pinned filters are different, then pinned filters will not be included in the URL, and opening the URL will inherit any pinned filters that are present.

[ThomThomson]

In looking into this issue again, it seems like even our fix that makes snapshot URLs avoid adding filters in the _g portion of the URL when no pinned filters are present doesn't fix this issue. Anything at all in the _g portion of the URL will cause this problem, even a time range.

That said, I have reprioritized this to impact:low because there is a workaround. When creating these links, dashboard authors can simply remove the _g portion entirely.

In terms of fixing this problem, I don't think it would actually be done on the dashboard side, it would involve changing the unified search bar's global state mechanism to allow partial overwriting of the state. Considering the low usage of the pinned filters setting and the complexity of the fix, I wouldn't recommend fixing this at the moment. @stratoula for visibility.

[ThomThomson]

Closing this for the time being as it is unlikely to be prioritized from the Visualizations side, and we're working on making markdown navigation obsolete with the Navigation Embeddable.