feat(desktop): group the Issues List by status or by priority
Merged
DA
11d ago+213+213+012345678901234567890123456789-19-19-01234567890123456789
Follow-up to #3667, from the plan Improve Issues board ("Filter and group"). The orchestrator approved grouping by status or priority for the List only, kept like the other view choices, with no board swimlanes.
What changed
- View options → Group by (Status / Priority), shown only while the List is up. The board's columns are already its statuses, so it offers no grouping.
- Grouped by priority: Urgent, High, Medium, Low, then No priority, with empty priorities left out. Inside each priority, rows run in the List's status order (work under way first), then most recently changed first.
- Grouped by status: the same as before.
- Kept like Board vs List: the choice is stored with
readKept/writeKeptunderluke.issuesGrouping. It is not a synced setting and has no Settings row. Choosing a grouping releases the keyboard from the row the page came back from, as choosing a layout does. - Model:
ISSUE_GROUPING,IssueGroupingandissueListGroups(issues, grouping)are in@luke/features'issue-list-model.ts.IssueListdraws whatever headings it returns.
Tests
issue-list-model.test.ts:- By priority: the most pressing first, No priority last, empty priorities left out, and status order then recency inside each.
- By status: the same headings as before, in their words.
issues-page.test.ts: the board offers no Group by. In the List, Group by → Priority heads issues by priority, the choice survives a remount, and Status brings the status headings back. It fails without this change.- The test helper
labelledItemnow prefers an open submenu's item, since "Priority" is both a Group by choice and a filter submenu.
Screenshots
From the real components in a browser harness over synthetic issues (dark theme).


No run.sh --preview Mac run is needed: this is renderer-only.
Made with Luke