feat(desktop): group the Issues List by status or by priority

Merged
DA
11d ago
+213-19

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/writeKept under luke.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, IssueGrouping and issueListGroups(issues, grouping) are in @luke/features' issue-list-model.ts. IssueList draws 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 labelledItem now 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).

Group by submenu in the List's View options

The List grouped by priority

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

Made with Luke


Devin Review