Problem
The search modal matches on issue key, tag, and summary. Status is shown in the result rows but cannot be searched. Finding "every issue currently in state X" (e.g. every release candidate) is not possible without scrolling the overview and eyeballing the status column.
The existing open/closed toggle on the overview is a coarse binary filter and does not answer "which issues are in a specific status".
Proposal
Two reasonable directions, either would work — pick whichever fits the mental model best:
- Extend the search modal with a prefix syntax alongside the existing tag prefix, so a query like
status:"Release Candidate" returns every matching issue.
- Add a status filter to the overview — a picker that lists the distinct statuses present in the cache and narrows the table to one of them.
Option 2 is probably closer to how status membership actually feels (a set-membership question, not a fuzzy match), but option 1 is a smaller change.
Out of scope
- Any change to how statuses are synced or stored; they are already on the cached issue rows.
Problem
The search modal matches on issue key, tag, and summary. Status is shown in the result rows but cannot be searched. Finding "every issue currently in state X" (e.g. every release candidate) is not possible without scrolling the overview and eyeballing the status column.
The existing open/closed toggle on the overview is a coarse binary filter and does not answer "which issues are in a specific status".
Proposal
Two reasonable directions, either would work — pick whichever fits the mental model best:
status:"Release Candidate"returns every matching issue.Option 2 is probably closer to how status membership actually feels (a set-membership question, not a fuzzy match), but option 1 is a smaller change.
Out of scope