Skip to content
Motir
Start free

moooon

Motir

Vibe your whole project. Bring an idea — Motir's three AI layers plan it, track it, and ship it, end to end. You're looking at Motir, built in Motir.

  • Vibe Project
  • Open Source
  • AI Agent
  • AI Loop
1
requests
0
upvotes
145
planned
1,361
shipped
Follow  — continues on app.motir.co
Request a featureAtom feed

← Motir · Work items

MOTIR-102Done

2.4.4 Inline controls: workflow-aware status + assignee

Estimate: 14m · Depends on: 2.4.1, 2.3.6

The two write affordances the scope names — and the ONLY ones on the detail page (everything else is the Edit form). Both REUSE 2.3.6's components + gated actions; this Subtask wires them inline, it does not build new mutation primitives.

Status control (workflow-aware). The header status pill becomes a StatusPicker (2.3.6) that offers only the LEGAL next statuses for the current one — the project's transitions in restricted mode, any status in open mode (2.2's canTransition / the workflow context already in the getIssueDetail bundle). Selecting one calls 2.2.4's gated updateStatus via a detail-page Server Action (changeStatusAction — reuse 2.3.6's if its signature fits, else a thin sibling); an illegal/stale transition surfaces the typed error inline; success toasts + revalidatePaths the detail route so the pill + the activity trail reconcile.

Assignee control. The sidebar assignee field becomes an AssigneePicker (2.3.6, a workspace-member combobox) that reassigns via the now-status-free updateWorkItem (2.3.6's finding-#46 cleanup) through an updateAssigneeAction — assignee is a non-status patch field, so it rides the ordinary patch path (which still writes a revision). "Unassign" is supported (null assignee). Optimistic + toast + revalidate. Permission: any project member can change status/assignee in v1 (no per-field RBAC until Epic 6) — but the Server Actions still carry the explicit workspaceId/membership gate (finding #26).

Acceptance criteria

  • Status control offers exactly the legal next statuses (restricted: transition rows; open: all); choosing one persists via 2.2.4's updateStatus; an illegal/stale move surfaces the typed error inline and does not change the pill.
  • Assignee control reassigns (and unassigns) via the status-free updateWorkItem; a revision row is written for the change.
  • Both controls are Server-Action-gated (workspace + membership); a forged cross-workspace target 404s; no client-trusted ids.
  • Both reuse 2.3.6's StatusPicker/AssigneePicker — no parallel components; the detail page and edit form share them.
  • Vitest (real Postgres) over the two actions: legal status change, illegal rejection, reassign + unassign, cross-workspace 404. Component test: the status control lists only legal targets. shell-a11y stays green with the controls rendered.

Context refs

  • 2.3.6's StatusPicker / AssigneePicker + changeStatusAction / the status-free updateWorkItem (finding #46) — reuse, don't rebuild
  • workItemsService.updateStatus (2.2.4) + workflowsService.canTransition (2.2.3) — the gated paths
  • 2.4.1's IssueDetailDto workflow context (statuses + legal transitions) — the picker's option source
  • motir-core/CLAUDE.md — Server Action / 4-layer / workspaceId-gate rules