Carry search filters into widget replay search#26151
Conversation
Replaying a dashboard widget previously dropped any search filters configured on it — only the query string, time range, streams, and parameters travelled along. ReplaySearchButton now also accepts the widget's `filters` (a `FiltersType` list of `SearchFilter`), serialises them into the local-storage payload that the new search page pulls out via the `session-id` query param, and ensures the session-id is added to the URL whenever filters or parameters are present. NewSearchPage's session reader is widened to extract `filters` from the stored payload and forwards them via `useCreateSavedSearch` → `ViewGenerator` → `QueryGenerator` (which already accepts a 6th `searchFilters` positional arg, just lacking a caller). Also realigns `QueryGenerator`'s `SearchFilter` import to `views/types` to match what `Query.filters` actually stores — the previous `components/event-definitions/event-definitions-types` flavour required fields (`id`, `title`, `disabled`, `negation`) that widget filters don't necessarily carry. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
There was a problem hiding this comment.
Pull request overview
This PR carries dashboard widget search filters through replay search so the replayed search matches the widget’s original query context.
Changes:
- Persists widget filters with replay session state and restores them in
NewSearchPage. - Threads
searchFiltersthrough saved-search/view/query generation. - Adds replay-button tests and an unreleased changelog entry.
Reviewed changes
Copilot reviewed 8 out of 8 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
graylog2-web-interface/src/views/pages/NewSearchPage.tsx |
Reads replay state including filters from local storage and passes filters into saved search creation. |
graylog2-web-interface/src/views/logic/views/ViewGenerator.ts |
Forwards restored filters into query generation. |
graylog2-web-interface/src/views/logic/views/UseCreateSavedSearch.ts |
Adds searchFilters to saved search creation props. |
graylog2-web-interface/src/views/logic/queries/QueryGenerator.ts |
Uses the canonical views SearchFilter type. |
graylog2-web-interface/src/views/components/widgets/WidgetActionsMenu.tsx |
Supplies widget filters to the replay search button. |
graylog2-web-interface/src/views/components/widgets/ReplaySearchButton.tsx |
Adds filter-aware session IDs and persists filters on replay. |
graylog2-web-interface/src/views/components/widgets/ReplaySearchButton.test.tsx |
Covers replay links and local-storage persistence for filters. |
changelog/unreleased/pr-26151.toml |
Adds a bug-fix changelog entry. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| timeRange, | ||
| queryString, | ||
| parameters, | ||
| searchFilters, |
There was a problem hiding this comment.
TIL: toHaveBeenCalledWith (and other equality-checking assertions) do not consider {} to be different from { foo: undefined }. The idea is that a consumer of it would not experience a different behavior when accessing that subkey (i.e. argument.foo would be undefined for both {} and { foo: undefined }). So this comment from Copilot is not false, but not relevant/not an issue for the current change.
linuspahl
left a comment
There was a problem hiding this comment.
Works as described. Tested the following scenario:
User A (non-admin)
- creates a search filter and a dashboard
- shares the dashboard with User B (non-admin)
- User B opens dashboard and replays search for a widget.
User B sees a new search where the search filter is displayed and marked as "shared with me". Once User B tries to save the search, they see an alert for "A copy for 1 referenced search filter will be created, because of missing permissions."
This behavior makes sense imo.
* Carry search filters into widget replay search Replaying a dashboard widget previously dropped any search filters configured on it — only the query string, time range, streams, and parameters travelled along. ReplaySearchButton now also accepts the widget's `filters` (a `FiltersType` list of `SearchFilter`), serialises them into the local-storage payload that the new search page pulls out via the `session-id` query param, and ensures the session-id is added to the URL whenever filters or parameters are present. NewSearchPage's session reader is widened to extract `filters` from the stored payload and forwards them via `useCreateSavedSearch` → `ViewGenerator` → `QueryGenerator` (which already accepts a 6th `searchFilters` positional arg, just lacking a caller). Also realigns `QueryGenerator`'s `SearchFilter` import to `views/types` to match what `Query.filters` actually stores — the previous `components/event-definitions/event-definitions-types` flavour required fields (`id`, `title`, `disabled`, `negation`) that widget filters don't necessarily carry. * Add changelog snippet for #26151 --------- (cherry picked from commit a4d1554) Co-authored-by: Dennis Oelkers <dennis@graylog.com> Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>
* Carry search filters into widget replay search Replaying a dashboard widget previously dropped any search filters configured on it — only the query string, time range, streams, and parameters travelled along. ReplaySearchButton now also accepts the widget's `filters` (a `FiltersType` list of `SearchFilter`), serialises them into the local-storage payload that the new search page pulls out via the `session-id` query param, and ensures the session-id is added to the URL whenever filters or parameters are present. NewSearchPage's session reader is widened to extract `filters` from the stored payload and forwards them via `useCreateSavedSearch` → `ViewGenerator` → `QueryGenerator` (which already accepts a 6th `searchFilters` positional arg, just lacking a caller). Also realigns `QueryGenerator`'s `SearchFilter` import to `views/types` to match what `Query.filters` actually stores — the previous `components/event-definitions/event-definitions-types` flavour required fields (`id`, `title`, `disabled`, `negation`) that widget filters don't necessarily carry. * Add changelog snippet for #26151 --------- (cherry picked from commit a4d1554) Co-authored-by: Dennis Oelkers <dennis@graylog.com> Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>
* Carry search filters into widget replay search Replaying a dashboard widget previously dropped any search filters configured on it — only the query string, time range, streams, and parameters travelled along. ReplaySearchButton now also accepts the widget's `filters` (a `FiltersType` list of `SearchFilter`), serialises them into the local-storage payload that the new search page pulls out via the `session-id` query param, and ensures the session-id is added to the URL whenever filters or parameters are present. NewSearchPage's session reader is widened to extract `filters` from the stored payload and forwards them via `useCreateSavedSearch` → `ViewGenerator` → `QueryGenerator` (which already accepts a 6th `searchFilters` positional arg, just lacking a caller). Also realigns `QueryGenerator`'s `SearchFilter` import to `views/types` to match what `Query.filters` actually stores — the previous `components/event-definitions/event-definitions-types` flavour required fields (`id`, `title`, `disabled`, `negation`) that widget filters don't necessarily carry. * Add changelog snippet for #26151 --------- (cherry picked from commit a4d1554) Co-authored-by: Dennis Oelkers <dennis@graylog.com> Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>
Note: This needs a backport to previous versions.
Description
When clicking "Replay search" on a dashboard widget that has search filters configured, the resulting search now includes those filters. Previously they were dropped, so the replayed search returned a broader result set than the widget.
Filters are persisted to local storage under the replay
session-id(alongside parameters) and picked up byNewSearchPagewhen it builds the saved search view.Motivation and Context
Fixes Graylog2/graylog-plugin-enterprise#8869. The replay button promises to land the user on the same search the widget ran, but it was only forwarding query/timerange/streams/parameters — search filters were silently lost.
How Has This Been Tested?
ReplaySearchButton.test.tsx:session-idwhen filters are presentsession-idwhen neither parameters nor filters are present (or filters list is empty)NewSearchPagecan read them backScreenshots (if appropriate):
Types of changes
Checklist: