Skip to content

Add board-level filter by inline field - #1223

Open
jeremysintes wants to merge 2 commits into
community-archive:mainfrom
jeremysintes:feature/filter-by-inline-field
Open

Add board-level filter by inline field#1223
jeremysintes wants to merge 2 commits into
community-archive:mainfrom
jeremysintes:feature/filter-by-inline-field

Conversation

@jeremysintes

Copy link
Copy Markdown

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.

  • Fields with more than 12 distinct values are excluded from the field dropdown (e.g. a due date is usually near-unique per card, so it isn't a meaningful filter axis and would make the dropdown unusably long).
  • An active text search and field filter compose with AND semantics, reusing 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).
  • Added a docs page (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/MenuItem submenu (field list → value list), matching the existing "Board view" button's pattern. MenuItem's onClick event 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 sidesteps Menu positioning 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.md about 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

  • Typechecked (tsc --noemit) — no new errors vs. main
  • Manually tested in a real vault: filtering by field/value narrows lanes and cards correctly, clearing restores the board, toggling the panel open/closed preserves the active filter, combining with text search applies AND semantics
  • No automated tests added (repo doesn't appear to have a test suite for UI behavior)

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).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant