Add board-level filter by inline field - #1223
Open
jeremysintes wants to merge 2 commits into
Open
Conversation
Adds a dedicated filter icon next to Search in the board header. Clicking it opens two inline dropdowns (field, then value) built from the board's existing inline fields (e.g. [assignee:: Alex]), narrowing the board to matching lanes/cards the same way search already does. A second click collapses the picker into a small chip while the filter stays applied. Fields with more than 12 distinct values are excluded from the field dropdown (e.g. due dates are usually near-unique per card, so they aren't a meaningful filter axis and would make the dropdown unusably long). The filter and an active text search compose with AND semantics, sharing the existing SearchContext lanes/items sets rather than adding a second hide path. The header button has its own show-field-filter setting, following the existing pattern for the other header buttons (Search, Board view, etc). Note: I first tried a cascading Menu/MenuItem submenu (field list -> value list), matching the existing "Board view" button's pattern, but MenuItem's onClick event didn't reliably carry usable position data for positioning the second menu in this environment. Falling back to inline native <select> elements (same DOM slot as the search bar) sidesteps that entirely and needed no Menu API positioning at all. Co-authored with Claude (Anthropic) — this PR was built through an interactive Claude Code session, then reviewed and adjusted by me. Flagging this explicitly per the note in MAINTAINERS.md.
I added the new show-field-filter key to the settings interface, the settings UI toggle, and the header-button gate, but missed adding it to the computed-settings defaulting block (the ?? true fallbacks a few lines below show-board-settings). Without a default there, the setting read back as undefined on any board that never explicitly set it, which is every board — so the filter button silently disappeared as soon as the plugin actually reloaded with this build (caught this after reload, not before, sorry — should have tested a real disable/enable cycle before opening the PR rather than trusting the already-mounted view).
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.
Summary
Adds a dedicated filter icon next to Search in the board header. Clicking it opens two inline dropdowns — field, then value — built from the board's existing inline fields (e.g.
[assignee:: Alex]), narrowing the board to matching lanes/cards the same way search already does. A second click collapses the picker into a small chip while the filter stays applied; the "x" clears it.SearchContextlanes/items sets rather than adding a second hide path.show-field-filtersetting, following the existing pattern for the other header buttons (Search, Board view, etc).docs/How do I/Filter a Kanban board.md) mirroring the existing "Search a Kanban board" page. No screenshot included — happy to add one if useful, just didn't want to source it from a personal vault.Implementation note
I first tried a cascading
Menu/MenuItemsubmenu (field list → value list), matching the existing "Board view" button's pattern.MenuItem'sonClickevent didn't reliably carry usable position data for positioning the second menu in my testing, so I fell back to inline native<select>elements in the same DOM slot as the search bar — this sidestepsMenupositioning entirely and keeps the UI consistent with how search already works.Disclosure
This PR was built through an interactive Claude Code session (Anthropic), then reviewed and tested by me end-to-end in my own vault before opening this PR. I'm flagging this explicitly per the note in
MAINTAINERS.mdabout LLM-assisted contributions — wanted to be upfront rather than silent about it, and am glad to adjust anything that doesn't fit the codebase's conventions.Test plan
tsc --noemit) — no new errors vs.main