[Drilldowns] Fix missing $store in filter state syncing edge case #61261
Conversation
Dosant
changed the title
|
Pinging @elastic/kibana-app-arch (Team:AppArch) |
Dosant
added
review
v7.8
v7.8.0
release_note:skip
Dosant
changed the title
|
@elasticmachine merge upstream |
| @@ -91,15 +91,21 @@ export const connectToQueryState = <S extends QueryState>( | |||
| } else if (syncConfig.filters === FilterStateStore.GLOBAL_STATE) { | |||
| if ( | |||
| !initialState.filters || | |||
| !compareFilters(initialState.filters, filterManager.getGlobalFilters(), COMPARE_ALL_OPTIONS) | |||
| !compareFilters(initialState.filters, filterManager.getGlobalFilters(), { | |||
There was a problem hiding this comment.
The fix does work as expected.
However, as far as I understand, the problem with the filters coming in from initialState.filters.
I think it would be more correct, if we updated any filter without a store value to FilterStateStore.APP_STATE.
What do you think?
There was a problem hiding this comment.
Since $store was recently added and is optional would be hard to find all places where filters could come with missing $store. e.g., (link generations with missing $store in filters).
Also there are old kibana versions urls which are out of our control and old saved objects where filters are missing $store.
Apps work with missing $store, which is great. But would be also nice to fix this possible edge case with url syncing.
|
@elasticmachine merge upstream |
💚 Build SucceededHistory
To update your PR or re-run it, just comment with: |
…astic#61261) Co-authored-by: Elastic Machine <[email protected]>
…1261) (#61954) Co-authored-by: Elastic Machine <[email protected]> Co-authored-by: Elastic Machine <[email protected]>
Summary
Part of #61230
Originally I put this fix into #60087, but as it has nothing to do with drilldowns, extracting into separate pr.
In drilldown branch during navigating to dashboard filters were generated without
storevalue explicitly set (this could theoretically happen in other places, as the value is optional).In url we were setting those filters into either
_aor_gquery param, which makes it clear if filter is unpinned or pinned.After navigation
storewas add to the filter object, changing it's shape and state syncing utils run a redundant browser history update which broke back button.This pr change makes sure that data service state syncing utilities are ignoring update of internal filter's
$statevalue if specific type of filters (pinned or unpinned) is being synced.Testing
It is hard to test without drilldowns branch context: #60087
Functional test will be added together with drilldown #60087 (comment)
It is possible to "mimic" the navigation which will happen in drilldown:
$store.statepart from the filter object in the link.Expected behaviour: navigated back to origin dashboard
Current in master: back didn't work