feat(ui): add ascending/descending toggle to work-item ordering

[cavidelizade]

Feature summary

Adds an ascending/descending toggle to the saved-view order-by control, so the same order key can be viewed in either direction.

Linked issues / discussion

Closes #181

User-facing behavior

In the saved-view Display dropdown, under "Order by", there's now an Ascending / Descending toggle. Picking Descending reverses the current ordering; the choice is remembered with the rest of the display settings (persisted per view in localStorage).

What changed

UI (apps/web/)

• projectSavedViewDisplay.ts: new SavedViewOrderDirection ('asc' | 'desc') on SavedViewDisplaySettings, wired through the defaults, clone, and the persist parse/serialize (defaults to asc, older persisted settings included).
• issueListGroupAndSort.ts: sortIssuesByOrder takes a direction; descending is the ascending result reversed, so the toggle behaves consistently for every order key. buildGroupedIssues accepts and forwards orderDirection.
• ProjectSavedViewDisplayDropdown.tsx: the Ascending/Descending toggle.
• ViewDetailPage.tsx: reuses the shared sortIssuesByOrder (removing a duplicate local sorter) and passes the direction.

Database

• No schema changes.

Why this design

Reversing the ascending result keeps the toggle predictable regardless of a key's natural direction (e.g. "last created" is newest-first ascending, oldest-first descending), and reuses one sort implementation instead of two.

Test plan

• npm run typecheck, npm run lint, npm run build, prettier --check all green.
• Manual end-to-end on a saved view with four work items:
  1. Opened Display, Order by "Manual" (ascending) showed RKT-1, RKT-2, RKT-3, RKT-4.
  2. Clicked Descending, the list reversed to RKT-4, RKT-3, RKT-2, RKT-1 and the toggle stays selected.
• Tested with both light and dark theme.

Out of scope (follow-ups)

• The project work-items list and module pages use a separate display model; extending the toggle there can be a follow-up.

Rollout notes

None.

AI assistance

• AI tools were used — tool(s): Claude Code — and AI-assisted commits include a Co-Authored-By: trailer

Checklist

• PR title follows Conventional Commits and is <= 100 chars
• No --no-verify bypass
• Acceptance criteria from the linked issue are all met

Summary by CodeRabbit

• New Features

  • Added an ascending/descending order toggle for saved views.
  • Issue lists now respect the selected order direction when sorting grouped sections.

• Bug Fixes

  • Saved view settings now consistently preserve the chosen sort direction when loading and saving.
  • Grouped issue sorting now updates correctly when the order direction changes.

[coderabbitai]

📝 Walkthrough

Walkthrough

Adds an ascending/descending order direction setting to saved views. Extends SavedViewDisplaySettings, persistence parsing/serialization, and sortIssuesByOrder/buildGroupedIssues to accept direction. ViewDetailPage.tsx now delegates sorting to the shared helper, removing its local sort logic, and a new UI toggle is added to the display dropdown.

Changes

Order Direction Feature

Layer / File(s)	Summary
Settings type, defaults, and persistence apps/web/src/lib/projectSavedViewDisplay.ts	Adds SavedViewOrderDirection type, orderDirection field to settings/persisted interfaces, default value 'asc', ORDER_DIRECTIONS validation array, parsing fallback, and serialization support.
Sort helper direction support apps/web/src/lib/issueListGroupAndSort.ts	sortIssuesByOrder gains a direction parameter defaulting to 'asc', delegating ascending logic to a new sortAscending helper and reversing for descending; buildGroupedIssues and its internal sortIn forward orderDirection.
ViewDetailPage sorting integration apps/web/src/pages/ViewDetailPage.tsx	Removes local sortIssuesList/PRIORITY_RANK logic, imports and uses shared sortIssuesByOrder with settings.orderDirection, and updates the groupedSections memo dependencies.
Order direction UI control apps/web/src/components/project-saved-view/ProjectSavedViewDisplayDropdown.tsx	Adds DIRECTION_OPTIONS and a new button group in the "Order by" section to toggle settings.orderDirection, reflecting selection via aria-pressed and styling.

Estimated code review effort: 2 (Simple) | ~12 minutes

Sequence Diagram(s)

sequenceDiagram
  participant User
  participant ProjectSavedViewDisplayDropdown
  participant SavedViewSettings as projectSavedViewDisplay
  participant ViewDetailPage
  participant sortIssuesByOrder

  User->>ProjectSavedViewDisplayDropdown: Click direction button (asc/desc)
  ProjectSavedViewDisplayDropdown->>SavedViewSettings: update settings.orderDirection
  SavedViewSettings->>SavedViewSettings: serializeSettings() persists orderDirection
  ViewDetailPage->>SavedViewSettings: read settings.orderDirection
  ViewDetailPage->>sortIssuesByOrder: sortIssuesByOrder(list, orderBy, orderDirection)
  sortIssuesByOrder->>sortIssuesByOrder: sortAscending(list, orderBy)
  sortIssuesByOrder-->>ViewDetailPage: return ordered/reversed list
  ViewDetailPage-->>User: render grouped, ordered issues

Loading

Poem

A hop, a click, direction set,
Ascending, descending, no regret,
I sort my carrots high to low,
Then flip the pile just to know,
Thump thump — the view detail page shows it so! 🐇

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title is Conventional Commits-compliant and clearly describes the main UI change.
Description check	✅ Passed	The PR description mostly matches the template, covering summary, linked issue, changes, rationale, tests, rollout, and checklist.
Linked Issues check	✅ Passed	The changes satisfy #181 by adding the asc/desc toggle and passing orderDirection through sorting.
Out of Scope Changes check	✅ Passed	No clearly unrelated code changes are introduced beyond feature support and a small shared-sort refactor.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

🧹 Nitpick comments (2)

apps/web/src/components/project-saved-view/ProjectSavedViewDisplayDropdown.tsx (1)

265-285: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low value

Solid implementation with correct accessibility semantics.

aria-pressed and role="group"/aria-label are correctly applied for the toggle buttons, and the direction is wired into settings.orderDirection consistently with the rest of the dropdown's update pattern.

One minor observation: this button-group is a bespoke inline implementation distinct from the existing RadioRow component used for groupBy/orderBy just above it. Since there are only two mutually-exclusive options, extracting a shared toggle-button-group helper (or reusing RadioRow styled differently) could reduce style duplication, but given the small footprint this is optional.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@apps/web/src/components/project-saved-view/ProjectSavedViewDisplayDropdown.tsx`
around lines 265 - 285, No functional issue needs to be fixed here; the
`ProjectSavedViewDisplayDropdown` direction buttons already use the correct
accessibility and state-update patterns. If you want to address the minor style
duplication noted in the review, consider extracting this inline toggle-button
group into a shared helper or reusing `RadioRow` alongside the existing
`settings.orderDirection` wiring, but this is optional and not required for
correctness.

apps/web/src/pages/ViewDetailPage.tsx (1)

434-669: 📐 Maintainability & Code Quality | 🔵 Trivial | 🏗️ Heavy lift

Grouping logic is fully duplicated from buildGroupedIssues.

Only the sort step was switched to the shared sortIssuesByOrder; the entire groupBy switch (states/priority/cycle/module/labels/assignees/created_by, ~220 lines) is copy-pasted from issueListGroupAndSort.ts. This PR needed to update orderDirection handling in two places to stay consistent — evidence that this duplication already causes double maintenance. Consider calling buildGroupedIssues from this file directly (reconciling the minor title()/isFlat differences) instead of keeping a parallel implementation.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@apps/web/src/pages/ViewDetailPage.tsx` around lines 434 - 669, The
groupedSections useMemo in ViewDetailPage is duplicating the same groupBy logic
that already exists in buildGroupedIssues, creating a second source of truth for
grouping and ordering. Replace the local
states/priority/cycle/module/labels/assignees/created_by switch with a call to
buildGroupedIssues, and adapt its result here for the local title/isFlat needs
instead of maintaining a parallel implementation. Keep the shared
sortIssuesByOrder behavior, and ensure settings.groupBy, settings.orderBy, and
settings.orderDirection still flow through the shared helper.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In
`@apps/web/src/components/project-saved-view/ProjectSavedViewDisplayDropdown.tsx`:
- Around line 265-285: No functional issue needs to be fixed here; the
`ProjectSavedViewDisplayDropdown` direction buttons already use the correct
accessibility and state-update patterns. If you want to address the minor style
duplication noted in the review, consider extracting this inline toggle-button
group into a shared helper or reusing `RadioRow` alongside the existing
`settings.orderDirection` wiring, but this is optional and not required for
correctness.

In `@apps/web/src/pages/ViewDetailPage.tsx`:
- Around line 434-669: The groupedSections useMemo in ViewDetailPage is
duplicating the same groupBy logic that already exists in buildGroupedIssues,
creating a second source of truth for grouping and ordering. Replace the local
states/priority/cycle/module/labels/assignees/created_by switch with a call to
buildGroupedIssues, and adapt its result here for the local title/isFlat needs
instead of maintaining a parallel implementation. Keep the shared
sortIssuesByOrder behavior, and ensure settings.groupBy, settings.orderBy, and
settings.orderDirection still flow through the shared helper.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: dc7d88f0-a26f-4c57-adbb-42a1a18e70c2

📥 Commits

Reviewing files that changed from the base of the PR and between 15c9d41 and d5c013b.

📒 Files selected for processing (4)

• apps/web/src/components/project-saved-view/ProjectSavedViewDisplayDropdown.tsx
• apps/web/src/lib/issueListGroupAndSort.ts
• apps/web/src/lib/projectSavedViewDisplay.ts
• apps/web/src/pages/ViewDetailPage.tsx