MotirBuilding in public
MOTIR · moooon
onMotir
You’re viewing a public project. Anyone can view it — no account needed. Sign in to submit, upvote, or comment on requests.View-only — you can’t edit work items
MOTIR-358

6.5 Project admin surface

Done
Description

The unified project-settings area: one grouped settings navigation wrapping every per-project admin page — Details (this story; 6.8 makes it editable), Members & Access (6.4), Workflow (2.2.5), Boards (3.6/3.7), Estimation (4.3), Fields (5.3), Components (5.4) — behind one chrome, replacing the flat card hub and the per-page back-crumbs. Later admin stories (6.6 Automation, 6.8 Details editing + key change) mount by adding a registry entry.

The verified mirror shape (and where we deviate, recorded). Jira project settings is a dedicated sidebar AREA entered from the project nav: a grouped left nav of settings pages with a way back to the project, LANDING on Details — which owns project name/key/avatar and the danger zone. Adopted 1:1. Deviations, each justified: no Features toggle page (board TYPE — 3.7 multi-board + 4.5 Scrum — owns that axis in Motir); no project-level Notifications admin (per-user preferences are the 5.7 surface; an admin-owned scheme has no stated use case); no Apps page (no marketplace). The 5.3 work-type-layout admin remains a documented extension with a reserved registry slot.

The settings-nav registry (the load-bearing piece). One typed entry per page — { id, group, href, icon, labelKey, access } — drives the area nav, the command-palette deep links, and the totality test: every settings/project/** route has exactly one entry, enforced by a suite that fails on drift (the 6.1 totality-guard pattern; mistake #29). Access predicates ride the SHIPPED 6.4.3 policy: admin manages; member gets the read-only states the pages already ship (rung 2 — 5.4/6.4 set that precedent); a role without browse access sees neither nav entry nor page (the 6.4.4 no-access state). Groups: General (Details), Access (Members & access), Work (Workflow, Boards, Estimation, Fields, Components), Automation (the 6.6 slot).

Routes are preserved; the landing moves. Every existing page keeps its URL (settings/project/workflow|board|estimation|members + the Epic-5 fields/components — zero deep-link breakage, no redirects needed); /settings/project itself becomes the Details page (read-only identity — name, key, avatar, workspace, created — plus the re-homed Archive danger zone, mirroring Details-owns-the-danger-zone), and the card hub retires. Story 6.8 grows THIS page with editing + the key-change machinery.

Real-product completeness (finding #57 axes). The nav is bounded (≤ ~10 entries — no scale surface; each page owns its own bounded reads); states: no-active-project empty state (kept), per-role nav filtering, the no-access direct-nav state, narrow- viewport nav behaviour (designed, not improvised); a11y: the nav is a labelled navigation landmark with aria-current, fully keyboard-operable, strict-axe-clean; all strings via next-intl (en byte-identical, zh).

Out of scope (documented extension slots, each justified): Details editing + project-key change with old-key redirects (Story 6.8 — it grows the 6.5.3 page); Automation rules (Story 6.6 — the reserved Automation slot); workspace/account settings unification (separate scopes — Jira likewise separates site admin from project settings; they keep their own pages); per-work-type field layouts (the 5.3 extension, slot reserved); a settings search box (Jira ships one at site-admin scale; ~10 entries do not earn it).

Verification

  • Pull the Story branch, pnpm install, pnpm db:seed, pnpm dev (no migration — this story adds no schema).
  • pnpm test:coverage — the registry totality + access-matrix suites green; all 6.5 files ≥90% branch/fn/line.
  • The area: sign in as zhuyue@motir.co / !QAZ1qaz → the app sidebar Settings item → lands on Details at /settings/project (name, key PROD, avatar, workspace, created — read-only, with the "editing arrives with project-details editing" seam — plus the Archive danger zone), inside the grouped settings nav matching design/projects/settings-area.mock.html (General / Access / Work groups; active state on Details).
  • Walk every section: Members & access, Workflow, Boards (incl. switching boards via ?board=), Estimation, Fields, Components — each renders its existing page inside the area chrome, nav active-state tracks, the old back-crumbs are gone, and the page URLs are unchanged (open /settings/project/workflow directly in a new tab → same page, area chrome present).
  • Roles: as a non-admin member (bophilips@motir.co) the nav shows the sections their role can open and admin-managed pages render their shipped read-only states; a user without browse access on a private project hits the 6.4.4 no-access state on direct nav (no settings nav leak).
  • Command palette: ⌘K lists the settings sections (from the registry); picking one deep-links into the area.
  • Narrow viewport: at mobile width the settings nav collapses per the design (reachable, not clipped); spot-check drag-free keyboard traversal of the whole nav.
  • pnpm test:e2e --grep settings-area — the Playwright journey passes.
  • a11y check: the strict axe sweep over the area chrome + Details page reports zero violations; nav is a labelled landmark with aria-current; colour via --el-*, shape via element tokens.