# 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