Repository navigation
Persist the match-anywhere search toggle in the URL - #74019
Conversation
Screen.Recording.2026-10-01.at.13.41.25.mov |
bbovenzi
left a comment
bbovenzi
left a comment
There was a problem hiding this comment.
How is our source of truth chain supposed to work here and then with #74021?
We only say when match anywhere is on. Do we also want an explicit match anywhere is off? Because otherwise we're going to localStorage or the user default.
If this is in url params, we should completely remove the localStorage option and only have global config + url param
The substring (match-anywhere) search toggle only lived in each browser's localStorage, so a filtered search could not be reproduced from a shared link: a colleague opening the URL saw prefix results unless they happened to have the same toggle enabled locally. Mirroring the toggle in a shareable URL param fixes that. The param lists the enabled searchbars by key so pages with several text filters stay unambiguous, and the per-searchbar localStorage preference remains the fallback when the URL does not carry it. closes: apache#73772
The toggle only recorded the positive, so turning match-anywhere off just dropped the param — a shared link then could not reproduce an off result for a recipient whose stored preference (or, with the stacked setting, default) was on. The param now carries an explicit `-key` entry for off, so both directions are shareable. The URL still wins over localStorage, and a key with no entry falls back to it.
ca94fb4 to
b1cc918
Compare
|
Updated, we are now capturing 'negative' for sharing urls.
Resolution order is url -> localstorage -> global setting (added in the following PR).
Yes indeed. Addressed in last commit. Screen.Recording.2026-10-02.at.11.08.24.mov
Localstorage is still usefull when navigating from within the application (because all those internal redirection links won't be providing those query params in the url). Typically:
|
The toggle already persists per-searchbar under the `advanced_search-<id>` localStorage key, so naming the URL param `advanced_search` too (rather than `match_anywhere`) makes it obvious the two are the same feature.
The substring ("match anywhere") search toggle only persisted in each browser's localStorage, so a filtered search could not be reproduced from a shared link — a colleague opening the URL saw prefix-only results unless they happened to have the same toggle enabled locally (#73772).
This mirrors the toggle in a shareable
match_anywhereURL param. It is a repeated param listing the searchbars whose toggle is on (e.g.?match_anywhere=dag_id&match_anywhere=run_id), so pages with several independent text filters stay unambiguous. A key present in the URL wins so a shared link reproduces the sender's results; otherwise the existing per-searchbar localStorage preference still applies, and toggling the control writes both.The change is a single central tweak to the
useAdvancedSearchhook, so every searchbar and per-filter toggle that already uses it is covered uniformly. No visual change — the existing toggle now just reflects into, and reads back from, the URL.closes: #73772
Was generative AI tooling used to co-author this PR?
Generated-by: Claude Code (Opus 4.8) following the guidelines