58 lines
3.0 KiB
Markdown
58 lines
3.0 KiB
Markdown
# Unit 6 Functional Design — Clarification Questions
|
|
|
|
I detected gaps in your responses that need clarification before I can complete the functional design.
|
|
|
|
## Gap: Backend endpoints missing for profile editing and password change
|
|
|
|
Your answers to Q1 and Q2 indicate the ProfilePage should:
|
|
- Allow editing **Name** and **Email** (Q2: C)
|
|
- Show a **Change Password** button (Q1: C, note "only Role is read-only")
|
|
|
|
However, the current backend API has **no endpoints** for these operations:
|
|
|
|
| Required operation | Needed endpoint | Currently exists? |
|
|
|---|---|---|
|
|
| Update name / email | `PUT /api/v1/Users/me` or `PATCH /api/v1/Users/{id}` | ❌ No |
|
|
| Change password | `POST /api/v1/Auth/change-password` or similar | ❌ No |
|
|
| Read own profile | `GET /api/v1/Users/me` (optional, or use AuthContext) | ❌ No |
|
|
|
|
These are additional backend changes not originally scoped for Unit 6. I need your decisions on each.
|
|
|
|
---
|
|
|
|
## Clarification Question 1: Backend endpoint for profile update (name + email)
|
|
|
|
Editing name and email requires a new backend endpoint. How should this be handled?
|
|
|
|
A) Add `PUT /api/v1/Users/me` to the backend in this unit — accepts `{ "name": string, "email": string }` and updates the current user's profile (recommended — required for the edit feature to function)
|
|
B) Add a backend endpoint but only allow editing name — email changes are too sensitive (require email verification flow which is out of scope)
|
|
C) Make the edit fields visible in the UI but non-functional for now (placeholder edits — form renders but the save button is disabled or shows "coming soon")
|
|
D) Other (please describe after [Answer]: tag below)
|
|
|
|
[Answer]: A
|
|
|
|
---
|
|
|
|
## Clarification Question 2: Change Password — functional or placeholder?
|
|
|
|
The "Change Password" button requires a new backend endpoint. How should this be handled in this unit?
|
|
|
|
A) Implement Change Password fully: add `POST /api/v1/Auth/change-password` to the backend — accepts `{ "currentPassword": string, "newPassword": string }` and changes the password (requires full backend + frontend implementation)
|
|
B) Show a "Change Password" button that opens a dialog, but the submit is a placeholder — shows "This feature is coming soon" (frontend only, no backend work)
|
|
C) Show a "Change Password" link/button but leave it disabled with a tooltip "Coming soon"
|
|
D) Other (please describe after [Answer]: tag below)
|
|
|
|
[Answer]: A
|
|
|
|
---
|
|
|
|
## Clarification Question 3: Profile data source after editing
|
|
|
|
When the user edits their name/email and saves, the AuthContext currently holds the logged-in user's data (set at login and refreshed on token refresh). After a successful profile update, how should the frontend reflect the change?
|
|
|
|
A) Call `auth/refresh` after a successful profile update — the refresh response returns updated user data, which updates AuthContext automatically (recommended — reuses existing infrastructure)
|
|
B) Update AuthContext directly in the frontend after a successful save (optimistic update — no extra API call)
|
|
C) Other (please describe after [Answer]: tag below)
|
|
|
|
[Answer]: A
|