IAM - My profile¶

Status: Implemented
Prefix: PRF
Module: iam
Feature: my-profile
Related: Sign-in, Change password, User management, Customer portal workspace

Purpose¶

A signed-in workspace user views and updates their own profile (full name and email). Password changes stay on the change-password flow. Role and lock status stay under admin user management.

Users and permissions¶

Any active signed-in workspace user (super_admin, admin, tenant_owner, or user) may read and update only their own profile. A caller who is not signed in receives 401. Locked users cannot sign in, so they cannot open this screen.

Requirements¶

ID	Priority	Requirement
PRF-01	Must	`GET /api/auth/me` with a valid session returns the signed-in user's public profile (`id`, `email`, `fullName`, `status`, `role`, and plan/tenant fields when present).
PRF-02	Must	`PATCH /api/auth/me` with a valid session updates that user's `fullName` and/or `email`. The response is 200 with the updated public profile. Role, status, and password cannot be changed on this endpoint.
PRF-03	Must	Full name is trimmed and required (1–200 characters). An empty or whitespace-only name is rejected with 400.
PRF-04	Must	Email is trimmed, stored in lower case, and must include a domain (same rule as registration). An invalid email is rejected with 400.
PRF-05	Must	Changing email to one that already belongs to another user returns 409 and leaves the profile unchanged.
PRF-06	Must	A missing or invalid session on PATCH receives 401 and the profile is unchanged.
PRF-07	Must	The customer portal has a My profile screen at `/profile` where the signed-in user edits full name and email, saves through PATCH, and sees success on the same page. Role is shown read-only. A link opens Change password.
PRF-08	Must	The customer portal header exposes a control that opens `/profile`.

Screens¶

My profile (/profile in the tenant workspace shell).

Form fields: Full name, Email (editable); Role (read-only label).
Actions: Save changes; link or button to Change password (/change-password); Back returns to workspace home.
Success shows a short confirmation on the page without signing the user out.
Validation and API errors are shown on the form.

Business rules¶

Only the signed-in user id from the session is updated; the request body must not include a target user id.
Email normalization matches registration and sign-in.
Updating full name or email does not end sessions and does not change the password.
Admin user management (USM) remains the path to lock accounts or edit another member.

Acceptance criteria¶

PRF-01: Given a valid session, when they call GET /api/auth/me, then the response is 200 with their public profile. Given no session, then the response is 401.
PRF-02: Given a signed-in user, when they PATCH a new full name, then 200 returns the updated profile and later GET me shows that name.
PRF-03: Given a blank full name, when they PATCH, then the response is 400 and the stored name is unchanged.
PRF-04: Given an email without a domain after @, when they PATCH, then the response is 400.
PRF-05: Given another account already uses an email, when they PATCH that email, then the response is 409.
PRF-06: Given no session, when they PATCH, then the response is 401.
PRF-07: Given the /profile screen, when they save a valid name and email, then the form shows success and the header shows the new name.
PRF-08: Given the workspace header, when they open the profile control, then /profile is shown.