# User Profile API

> **Prefix:** `/api/v1/user-profile` (plus the per-user tour endpoints under `/api/v1/my/tours`)

User medical profiles store health information that can be shared with doctors.

---

## POST `/api/v1/user-profile`

Create a medical profile for the authenticated user.

**Permission:** `AUTH`

### Request Body (`application/json`)
```json
{
  "name": "علی",
  "family": "احمدی",
  "fathers_name": "محمد",
  "national_code": "0012345678",
  "gender": "male",
  "blood_type": "A+",
  "marital_status": "married",
  "education": "لیسانس",
  "job": "مهندس",
  "address": "تهران، خیابان ولیعصر",
  "home_phone": "02112345678",
  "work_phone": "02198765432",
  "insurance_id": 1,
  "description": "توضیحات بیشتر",
  "sharing_with_user": true,
  "birthday": "1370-06-15",
  "date_of_birth": 648172800,
  "basic_insurance": "بیمه تأمین اجتماعی",
  "supplementary_insurance": "بیمه ایران",
  "other": {}
}
```

| Field | Type | Required | Description |
|-------|------|----------|-------------|
| `name` | string | ❌ | First name |
| `family` | string | ❌ | Last name |
| `fathers_name` | string | ❌ | Father's name |
| `national_code` | string | ❌ | National ID (10 digits) |
| `gender` | string | ❌ | `"male"` or `"female"` |
| `blood_type` | string | ❌ | `"A+"`, `"A-"`, `"B+"`, `"B-"`, `"AB+"`, `"AB-"`, `"O+"`, `"O-"` |
| `marital_status` | string | ❌ | `"single"` or `"married"` |
| `education` | string | ❌ | Education level |
| `job` | string | ❌ | Occupation |
| `address` | string | ❌ | Home address |
| `home_phone` | string | ❌ | Home phone number |
| `work_phone` | string | ❌ | Work phone number |
| `insurance_id` | integer | ❌ | Insurance ID |
| `description` | string | ❌ | Additional notes |
| `sharing_with_user` | boolean | ❌ | Allow doctors to view this profile |
| `birthday` | string | ❌ | Birthday in Jalali format `YYYY-MM-DD` |
| `date_of_birth` | integer | ❌ | Birthday as Unix timestamp |
| `basic_insurance` | string | ❌ | Basic insurance name |
| `supplementary_insurance` | string | ❌ | Supplementary insurance name |
| `other` | object | ❌ | Extra metadata |

### Response `201`
```json
{
  "success": true,
  "data": {
    "uuid": "profile-uuid-...",
    "name": "علی",
    "family": "احمدی",
    "gender": "male",
    "blood_type": "A+",
    "national_code": "0012345678",
    "sharing_with_user": true,
    "created_at": 1717000000
  }
}
```

### Errors
| Code | HTTP | Description |
|------|------|-------------|
| `ERR_AUTH_001` | 401 | Missing token |
| `ERR_VALIDATION_001` | 422 | `national_code` نامعتبر (رقم کنترلی/طول غلط) (`field: national_code`) |
| `ERR_PROFILE_001` | 409 | کد ملی قبلاً برای پروفایل کاربر دیگری ثبت شده (`field: national_code`) |
| `ERR_CONFLICT_001` | 409 | Profile already exists for this user |

---

## GET `/api/v1/user-profile/{uuid}`

Get a user profile.

**Permission:** `AUTH` — must be the profile owner, or a doctor if `sharing_with_user: true`, or `ROLE_ADMIN`

### Path Parameters
| Param | Type | Description |
|-------|------|-------------|
| `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 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`.

### Errors
| Code | HTTP | Description |
|------|------|-------------|
| `ERR_AUTH_001` | 401 | Missing token |
| `ERR_FORBIDDEN_001` | 403 | Not authorized to view this profile |
| `ERR_VALIDATION_002` | 404 | No profile or user matches the uuid |

---

## PATCH `/api/v1/user-profile/{uuid}`

Update a user profile.

**Permission:** `AUTH` — must be the profile owner

### Path Parameters
| Param | Type | Description |
|-------|------|-------------|
| `uuid` | string (UUID) | **Profile UUID or the owning User UUID** — both accepted; the profile is created if the current user has none yet |

### Request Body
Same fields as POST — all optional.

> **`national_code` server-side validation:** اگر `national_code` ارسال شود و **غیرخالی** باشد، با الگوریتم رقم کنترلیِ کد ملی ایران اعتبارسنجی می‌شود (ارقام فارسی/عربی به انگلیسی نرمال و به‌صورت لاتین ذخیره می‌شوند). مقدارِ نامعتبر با `422` رد می‌شود. ارسال `null` یا رشته‌ی خالی مجاز است (کد ملی اختیاری) و فیلد را پاک می‌کند.
>
> **یکتایی کد ملی:** کد ملی در کل سیستم یکتاست (یک کد ملی = یک بیمار). اگر کد ملی ارسالی قبلاً به پروفایل **کاربر دیگری** تعلق داشته باشد، با `409` و کد `ERR_PROFILE_001` رد می‌شود (`field: national_code`). پیام خطا شامل **شماره موبایلِ ماسک‌شده‌ی** صاحب کد است (مثلاً «این کد ملی قبلاً با شماره 0912****56 ثبت شده است»). در سطح دیتابیس هم با `UNIQUE INDEX uniq_profiles_national_code` تضمین شده (مقادیر `NULL` آزادند). همین قید روی مسیر ساخت بیمار توسط منشی (`POST /api/v1/patient`) نیز اعمال می‌شود.

### Response `200`
Updated profile object.

### Errors
| Code | HTTP | Description |
|------|------|-------------|
| `ERR_AUTH_001` | 401 | Missing token |
| `ERR_VALIDATION_001` | 422 | `national_code` نامعتبر (رقم کنترلی/طول غلط) (`field: national_code`) |
| `ERR_PROFILE_001` | 409 | کد ملی قبلاً برای پروفایل کاربر دیگری ثبت شده (`field: national_code`) |
| `ERR_FORBIDDEN_001` | 403 | Not the profile owner |
| `ERR_NOT_FOUND_001` | 404 | Profile not found |

---

## DELETE `/api/v1/user-profile/{uuid}`

Delete a user profile.

**Permission:** `ROLE_ADMIN`

### Response `200`
```json
{ "success": true, "data": { "message": "پروفایل حذف شد" } }
```

### Errors
| Code | HTTP | Description |
|------|------|-------------|
| `ERR_AUTH_001` | 401 | Missing token |
| `ERR_AUTH_006` | 403 | Not admin |
| `ERR_NOT_FOUND_001` | 404 | Profile not found |

---

## POST `/api/v1/user-profile/avatar`

Upload the current user's profile avatar. Creates the profile if it doesn't exist yet.

**Permission:** `IS_AUTHENTICATED_FULLY`

### Request
Raw file body with `Content-Disposition: filename="..."` and `Content-Type: application/octet-stream`.

### Response `200`
```json
{ "success": true, "data": { "avatar": "/uploads/avatars/2026-06/xxx.jpg", "url": "/uploads/avatars/2026-06/xxx.jpg" } }
```

The stored path is also returned as `avatar` in the profile GET/PATCH responses.

### Errors
| Code | HTTP | Description |
|------|------|-------------|
| `ERR_VALIDATION_001` | 422 | Missing or invalid file |
| `ERR_AUTH_001` | 401 | Missing token |

---

# Guided tours (admin panel)

The admin SPA ships a step-by-step tour per page. A tour runs automatically the first time a
user opens that page, and is available afterwards from the `?` button in the page header.
Which tours a user has already been through is stored server-side, so it follows the account
across browsers and devices.

Each tour carries a `version` in the frontend registry (`assets/admin/lib/tour/tours/*.ts`).
The tour auto-runs again when its version is higher than the stored one, which is how a rewritten
tour reaches users who already saw the old text.

Every non-admin page of the panel ships a tour. Adding one to a new page means: a file under
`assets/admin/lib/tour/tours/`, one line in `registry.ts`, and `tourId` on the page's `PageHeader`
— the shared `data-tour` anchors (`page-title`, `page-action`, `page-search`, `page-table`,
`page-pagination`) already come from `PageHeader`, `DataTable` and `Pagination`. A step whose
anchor is not on screen is dropped silently, so role-specific pages need no branching.
`PageHeader` auto-runs the tour once the page is ready; pass `tourReady={!isLoading}` when the
data arrives late.

## GET `/api/v1/my/tours`

Tours the current user has already been through.

**Permission:** `IS_AUTHENTICATED_FULLY`

### Response `200`
```json
{ "success": true, "data": { "seen": { "appointments": 1 } } }
```

`seen` is always an object; it is `{}` for a user who has not finished any tour yet.

| Field | Type | Description |
|-------|------|-------------|
| `seen` | object | tour id → highest version the user has seen |

### Errors
| Code | HTTP | Description |
|------|------|-------------|
| `ERR_AUTH_001` | 401 | Missing token |

---

## POST `/api/v1/my/tours/{tourId}/seen`

Record that the current user has been through a tour. Closing a tour part-way counts as seen —
the client sends this on tour close as well as on completion.

**Permission:** `IS_AUTHENTICATED_FULLY`

| Param | Type | Description |
|-------|------|-------------|
| `tourId` | string | Route-constrained to `[a-z0-9-]{1,64}`; anything else is a 404 |

### Request Body (`application/json`)
```json
{ "version": 1 }
```

| Field | Type | Required | Description |
|-------|------|----------|-------------|
| `version` | integer ≥ 1 | ✅ | Version of the tour definition that was shown |

### Response `200`
```json
{ "success": true, "data": { "tourId": "appointments", "version": 1 } }
```

Repeat calls update the same row. The stored version only ever moves forward, so replaying an
old tour from the `?` button cannot re-trigger a newer one.

### Errors
```json
{ "success": false, "data": null, "errors": [ { "code": "ERR_VALIDATION_001", "message": "نسخهٔ راهنما باید عددی بزرگ‌تر از صفر باشد", "field": "version" } ] }
```

| Code | HTTP | Description |
|------|------|-------------|
| `ERR_VALIDATION_001` | 422 | `version` missing, not an integer, or below 1 |
| `ERR_AUTH_001` | 401 | Missing token |
| — | 404 | `tourId` does not match the route constraint |
