Repository navigation
UI: Add match-anywhere toggle to the tags filter - #73616
Merged
pierrejeambrun merged 4 commits intoOct 21, 2026
Merged
Conversation
krisztiansala
requested review from
bbovenzi,
choo121600,
guan404ming,
pierrejeambrun,
ryanahamilton,
shubhamraj-git and
vatsrahul1001
as code owners
September 23, 2026 12:52
|
Congratulations on your first Pull Request and welcome to the Apache Airflow community! If you have any issues or are unsure about any anything please check our Contributors' Guide
|
krisztiansala
force-pushed
the
ui-advanced-search-tags
branch
from
September 24, 2026 07:06
071a1ef to
0b423b6
Compare
Contributor
Author
krisztiansala
force-pushed
the
ui-advanced-search-tags
branch
from
October 2, 2026 19:23
76e7194 to
356aca9
Compare
Follow-up to apache#66015. The Dags list Tags pill queries ``/dagTags`` with ``tag_name_prefix_pattern`` on every keystroke, so tag search only matches from the start of the name. Wire the existing advanced-search toggle into ``MultiSelectPill`` and set ``supportsAdvancedSearch`` on the tags config so users can opt back into substring (``tag_name_pattern``) matching, persisted per-filter in localStorage like the other searchbars.
…toggle - Drop newsfragments/73616.feature.rst per review - Add roundedRight option to AdvancedSearchToggle addon variant so it doesn't keep a rounded corner when the match-mode toggle follows it - Fix prettier formatting in TagsFilter.test.tsx
krisztiansala
force-pushed
the
ui-advanced-search-tags
branch
from
October 5, 2026 07:16
356aca9 to
9ac58a5
Compare
bbovenzi
approved these changes
Oct 6, 2026
Member
|
Unrelated CI failure, merging. |
|
Awesome work, congrats on your first merged pull request! You are invited to check our Issue Tracker for additional contributions. |
1 task done
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.



Follow-up to #66015.
Why
Since #64963 switched the UI to index-friendly
*_prefix_patternsearches, the Tags filter on the Dags list only matches tag names from the start — typing a middle substring yields nothing. #66015 restored substring matching for searchbars and text filter pills via the.*"match anywhere" toggle, but the Tags pill is aMultiSelectPillbacked by a paginated/dagTagsquery, so it never got the toggle.What
useDagTagsInfinitegains anadvancedSearchflag and spreads the input ontotagNamePattern(substringILIKE '%term%') ortagNamePrefixPattern(LIKE 'term%') — same pattern asuseDags.TagsFilterreadsuseAdvancedSearch(filter.config.key)so the pill's toggle state and the tag query share theadvanced_search-tagslocalStorage key.MultiSelectPillrendersAdvancedSearchToggle(variantaddon) right after the select whenconfig.supportsAdvancedSearchis set, and shows the sameLuRegexindicator on the collapsed pill thatTextSearchFilteruses. Other multiselect filters (teams, owners, timetable) filter static option lists client-side, so they don't set the flag and are unchanged.supportsAdvancedSearch: trueset on theTAGSfilter config; the flag's doc comment no longer says "text filters" only.Behavior is unchanged by default: prefix matching stays the default; opting into substring is per-browser per-filter, exactly like the existing toggles.
Screenshots
Verified locally with the vite dev server against mocked
/api/v2/dagTagsroutes that honor bothtag_name_prefix_patternandtag_name_pattern. Tags in the mock:CNDI,CNDI_DEV,LEGACY_CNDI_MIGRATION; inputcndi.Default (prefix) —
.*off, request sendstag_name_prefix_pattern=cndi, only prefix matches shown:.*enabled — request switches totag_name_pattern=cndi, substring matchLEGACY_CNDI_MIGRATIONappears:Collapsed pill shows the
.*indicator next to the selected tag, matching theTextSearchFilterbehavior:Test plan
pnpm vitest run src/components/FilterBar/filters/TagsFilter.test.tsx— new test file: prefix is the defaulttag_name_prefix_patternarg, toggling flips subsequent calls totag_name_pattern, the collapsed pill shows the regex indicator when enabled, and the toggle is absent withoutsupportsAdvancedSearchpnpm vitest runforFilterBar.test.tsxandSearchBar.test.tsx— 28 tests passpnpm lint(eslint + tsc) clean.*toggle →tag_name_patternrequest fired, substring-only tag rendered,aria-pressedand localStorage persist. Not verified against a full breeze backend.Was generative AI tooling used to co-author this PR?
Generated-by: Devin following the guidelines