3.0 KiB
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)
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)
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)