Adds profile and settings pages
This commit is contained in:
@@ -0,0 +1,154 @@
|
||||
# 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
|
||||
Reference in New Issue
Block a user