155 lines
6.0 KiB
Markdown
155 lines
6.0 KiB
Markdown
# Functional Design Plan — Unit 6: Profile, Settings & CMS Placeholder
|
|
|
|
**Status**: 🚧 In Progress
|
|
|
|
## Unit Context
|
|
|
|
**Unit**: Unit 6 — Profile, Settings & CMS Placeholder
|
|
**Type**: Frontend (React/TypeScript) + Documentation
|
|
**Depends on**: Unit 3 (AppLayout, RoleGuard), Unit 4 (useAvailabilityStatus, AvailabilityStatusBadge)
|
|
**Stories Covered**:
|
|
- US-15: View own profile
|
|
- US-16: View availability status in settings
|
|
- US-17: Access denied to System Settings for non-Owners
|
|
- US-20: View CMS management placeholder
|
|
|
|
**Key Deliverables** (from unit-of-work.md):
|
|
```
|
|
frontend/src/routes/
|
|
├── profile.tsx # ProfilePage: read-only user info
|
|
├── settings.tsx # SettingsPage: Owner-only, availability + placeholders
|
|
├── cms.tsx # CmsPage: Owner-only placeholder
|
|
├── 403.tsx # AccessDeniedPage
|
|
└── $404.tsx # NotFoundPage
|
|
|
|
README.md # Frontend Development section added
|
|
```
|
|
|
|
**Key Observations**:
|
|
- These are the final frontend pages; all shared infrastructure (ApiClient, AuthContext, AppLayout, RoleGuard) is already in place
|
|
- `useAvailabilityStatus` from Unit 4 can be reused directly in SettingsPage
|
|
- RoleGuard (from Unit 2) is already implemented; `/settings` and `/cms` need Owner-only guards
|
|
- The 403 and 404 pages can be pure presentational components (no data fetching)
|
|
- Routes `403.tsx` and `$404.tsx` need to be registered in the TanStack Router route tree
|
|
|
|
---
|
|
|
|
## Functional Design Steps
|
|
|
|
- [x] Step 1: Analyze unit context and existing code patterns
|
|
- [x] Step 2: Generate questions, collect answers
|
|
- [x] Step 3: Create `domain-entities.md`
|
|
- [x] Step 4: Create `business-rules.md`
|
|
- [x] Step 5: Create `business-logic-model.md`
|
|
- [x] Step 6: Create `frontend-components.md`
|
|
- [x] Step 7: Present completion message and await approval
|
|
|
|
---
|
|
|
|
## Questions
|
|
|
|
Please fill in the letter after each `[Answer]:` tag.
|
|
|
|
---
|
|
|
|
### Question 1: ProfilePage — displayed fields
|
|
|
|
The ProfilePage (US-15) should show the logged-in user's own information. Which fields should be displayed?
|
|
|
|
A) Name, Email, Role — three read-only fields sourced from AuthContext (no API call needed)
|
|
B) Name, Email, Role, Member Since (created date) — four fields; requires a `GET /api/v1/Users/{id}` or `/me` endpoint to fetch the date
|
|
C) Name, Email, Role, and a "Change Password" button (button can be a placeholder/not yet functional)
|
|
D) Other (please describe after [Answer]: tag below)
|
|
|
|
[Answer]: C, but only Role is read-only
|
|
|
|
---
|
|
|
|
### Question 2: ProfilePage — editability
|
|
|
|
Should the ProfilePage support editing any of the displayed information, or is it strictly read-only for now?
|
|
|
|
A) Strictly read-only — no edit capability in this unit (recommended — keeps scope minimal; edits can be a future feature)
|
|
B) Allow editing the display name only — inline edit with save
|
|
C) Allow editing email and/or name — full form
|
|
D) Other (please describe after [Answer]: tag below)
|
|
|
|
[Answer]: C
|
|
|
|
---
|
|
|
|
### Question 3: SettingsPage — availability section interaction
|
|
|
|
The SettingsPage (US-16) includes an availability section. Should it allow changing the availability mode, or just display the current status?
|
|
|
|
A) Display + change: show current mode with controls to switch between Online / Maintenance / Offline, and optionally set a custom message (recommended — Settings is the management location; Dashboard is read-only view)
|
|
B) Display only: show current availability status, link/note that says "Manage via API or a future admin tool"
|
|
C) Other (please describe after [Answer]: tag below)
|
|
|
|
[Answer]: A
|
|
|
|
---
|
|
|
|
### Question 4: SettingsPage — placeholder sections
|
|
|
|
Beyond the availability section, what placeholder sections should SettingsPage include to indicate planned future features?
|
|
|
|
A) One generic placeholder: "More settings coming soon"
|
|
B) Two placeholders: "Module Management" and "System Configuration" — with "Coming soon" labels
|
|
C) Three placeholders: "Module Management", "System Configuration", and "Branding / Theme" — styled as locked cards
|
|
D) Other (please describe after [Answer]: tag below)
|
|
|
|
[Answer]: C
|
|
|
|
---
|
|
|
|
### Question 5: CmsPage — placeholder content
|
|
|
|
The CmsPage (US-20) is an Owner-only placeholder. What should it display?
|
|
|
|
A) A simple "CMS coming soon" message with an icon and brief description of what will be here (recommended — clear intent without overdesigning)
|
|
B) A styled empty state card with a title "Content Management System" and a description of planned capabilities
|
|
C) Just a heading: "Content Management" with "Under construction" text
|
|
D) Other (please describe after [Answer]: tag below)
|
|
|
|
[Answer]: A
|
|
|
|
---
|
|
|
|
### Question 6: 403 AccessDeniedPage — navigation options
|
|
|
|
When a user hits a route they don't have permission for (e.g., a non-Owner accessing `/settings`), what should the 403 page offer?
|
|
|
|
A) Heading "Access Denied" + message explaining the page requires a higher role + "Back to Dashboard" button (recommended — clear and actionable)
|
|
B) Heading + message + "Go Back" (browser back) + "Back to Dashboard" buttons
|
|
C) Heading + message only — no navigation buttons (user uses browser back)
|
|
D) Other (please describe after [Answer]: tag below)
|
|
|
|
[Answer]: A
|
|
|
|
---
|
|
|
|
### Question 7: 404 NotFoundPage — navigation options
|
|
|
|
When a user navigates to a route that doesn't exist, what should the 404 page offer?
|
|
|
|
A) Heading "Page Not Found" + brief message + "Back to Dashboard" button (recommended)
|
|
B) Heading + message + "Go Back" (browser back) + "Back to Dashboard" buttons
|
|
C) Heading + message only
|
|
D) Other (please describe after [Answer]: tag below)
|
|
|
|
[Answer]: A
|
|
|
|
---
|
|
|
|
### Question 8: Unit test scope
|
|
|
|
Which parts of Unit 6 should have unit tests?
|
|
|
|
A) ProfilePage (renders correct user fields from AuthContext) + SettingsPage (availability display/interaction) + 403 page (renders message + navigation) + 404 page (renders message + navigation)
|
|
B) SettingsPage only — the other pages are too simple to warrant tests
|
|
C) All pages including CmsPage — full test coverage for the final unit
|
|
D) Other (please describe after [Answer]: tag below)
|
|
|
|
[Answer]: C
|