fix(user-profile): don't lazy-create when an admin views another user

resolveProfile created an empty profile for any caller with create-intent,
including an admin merely viewing someone else's profile. Restrict
lazy-create to the user's own profile; an admin reading another user's
missing profile now gets 404 with no side-effect record. Doc updated.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
hamed
2026-06-15 22:04:19 +03:30
co-authored by Claude Opus 4.8
parent 3f31f42fa0
commit 94d9f88cb2
3 changed files with 120 additions and 8 deletions
+1 -1
View File
@@ -97,7 +97,7 @@ Get a user profile.
|-------|------|-------------|
| `uuid` | string (UUID) | **Profile UUID or the owning User UUID** — both are accepted |
> **Auto-resolve & lazy-create:** `{uuid}` is first looked up as a profile uuid, then as a user uuid. If it is the **current user's** (or, for admins, any user's) uuid and that user has **no profile yet**, an empty profile is created and returned (HTTP 200) — so a freshly registered user always gets an editable profile instead of a 404. The response includes both the profile `uuid` and `user_uuid`; keep the profile `uuid` for subsequent PATCHes.
> **Auto-resolve & lazy-create:** `{uuid}` is first looked up as a profile uuid, then as a user uuid. If it is the **current user's own** uuid and they have **no profile yet**, an empty profile is created and returned (HTTP 200) — so a freshly registered user always gets an editable profile instead of a 404. An **admin** reading **another** user's missing profile gets `404` (no profile is created as a side effect of reading). The response includes both the profile `uuid` and `user_uuid`; keep the profile `uuid` for subsequent PATCHes.
### Response `200`
Full profile object including all fields (all `null` for a newly created empty profile). Response is double-nested: extract with `data.data`.