hamedandClaude Opus 5
6ab1eb6483
ownsRecord guards the patient record, not the rows underneath it, so
GET /api/v1/patient/{uuid}/wallet/transactions — and the recent_transactions
in the balance summary — returned the patient's entire history. Clinic A
could read what the patient paid at clinic B, down to the name of the staff
member who entered it.
The wallet stays the person's: the balance is still the sum of that user's
credits minus debits across every environment. Scoping it would show a
patient part of their own money and would make the running balance_after
meaningless. So this is attribution per row, not ownership per wallet.
The columns are deliberately named recorded_entity_type / recorded_entity_id
rather than entity_type / entity_id. TenantFilter keys on the latter and
would then scope the balance query too — the exact bug this avoids. The
naming is load-bearing, and both the entity and the architecture doc say so.
Rows that cannot be attributed — entered before this split, or outside any
environment such as a representation's commission — stay NULL and remain
visible everywhere; hiding them would make an existing patient's history
look deleted. The migration reports how many there are (0 in dev, all
attributable from payments and session references).
Consequence, documented in both docs/api/patient.md and the wallet tab: the
listed rows no longer sum to the displayed balance.
Removing the fix turns 3 of the 6 new tests red.
Tests: 902 backend (+6), 570 frontend. PHPStan unchanged at 17.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
ClinicPro — API Documentation Index
Base URL:
https://clinic-pro.ddev.site
API Prefix:/api/v1
Swagger UI:https://clinic-pro.ddev.site/api/doc— user:admin/ pass:clinic123
Authentication
All protected endpoints require:
Authorization: Bearer <JWT_TOKEN>
| Role | Description |
|---|---|
PUBLIC |
No token required |
AUTH |
Any valid JWT |
ROLE_ADMIN |
Admin user |
ROLE_DOCTOR |
Doctor user |
ROLE_CLINIC |
Clinic owner |
ROLE_SECRETARY |
Secretary |
Standard Response Envelope
// Success
{ "success": true, "data": { ... } }
// Paginated
{ "success": true, "data": [...], "meta": { "totalRecords": 100, "totalPages": 5, "currentPage": 1, "limit": 20 } }
// Error
{ "success": false, "data": null, "errors": [{ "code": "ERR_XXX_000", "message": "..." }] }
meta.limitاندازهٔ صفحهٔ واقعاً اعمالشده است. ریپازیتوریهاlimitدرخواستی را به سقف خودشان کاهش میدهند (مثلاً لیست پزشکان: سقف ۵۰)، پس برای پیمایش کامل بهmeta.totalPagesتکیه کن — نه به این فرض که «تعداد آیتم کمتر از limit درخواستی یعنی صفحهٔ آخر».
Persian digit normalization (global)
Persian (۰-۹) and Arabic (٠-٩) digits sent in numeric request fields are translated to Latin server-side, before the controller runs — src/Shared/EventSubscriber/NumericFieldNormalizerSubscriber.php. Every client benefits: the React admin panel, nobat724_front, and clinic-pro-tauri.
Applies to POST / PUT / PATCH requests under /api/v1/ with a JSON body, recursively through nested arrays.
Normalized keys:
mobile, mobile_number, telephone, phone, notification_mobile,
national_code, postal_code,
card_number, account_number, sheba, shaba, iban,
price_rials, amount_rials, amount, free_visit_price_rials,
insurance_price_rials, patient_share_rials, visit_price_rials,
duration_minutes, duration, commission_percent, coverage,
coverage_percent, franchise, ceiling, tax_percent,
base_insurance_discount_percent, supplementary_discount_percent
Only digits are translated — no characters are stripped, so IR in a sheba and - in a landline survive. Non-string values (int, bool, null) and keys outside the list are untouched, so a name like منشی شماره ۲ keeps its Persian digit.
// request
{ "mobile_number": "۰۹۱۲۳۴۵۶۷۸۹", "national_code": "۰۰۱۲۳۴۵۶۷۸", "name": "منشی شماره ۲" }
// what the controller sees
{ "mobile_number": "09123456789", "national_code": "0012345678", "name": "منشی شماره ۲" }
Adding a new numeric field to any endpoint? Add its key to
NUMERIC_KEYSin the subscriber, otherwise Persian digits reach the database.
Modules
| File | Domain | Endpoints |
|---|---|---|
| auth.md | Authentication — OTP, Login, JWT | 8 |
| doctor.md | Doctor profile & addresses | 11 |
| clinic.md | Clinics | 7 |
| clinic-invitation.md | Doctor invitations to clinics | 8 |
| appointment.md | Appointments & slot booking | 6 |
| appointment-settings.md | Weekly schedule, date overrides, holidays | 14 |
| payment.md | Payments (Mellat / Sep) | 5 |
| settlement.md | Wallet & settlement requests | 7 |
| rating.md | Ratings, comments, likes | 9 |
| secretary.md | Doctor secretaries | 5 |
| representation.md | Representations (agents) | 6 |
| sms.md | SMS send & templates | 10 |
| blog.md | Blog posts | 6 |
| specialty.md | Medical specialties | 5 |
| insurance.md | Insurances & doctor-insurance links | 10 |
| doctor-service.md | Doctor services | 5 |
| tag.md | Blog tags | 5 |
| location.md | Provinces & cities | 10 |
| user-profile.md | User medical profile | 4 |
| admin.md | Admin dashboard & management | 25+ |
Error Code Reference
| Code | Message (FA) | HTTP |
|---|---|---|
ERR_AUTH_001 |
توکن JWT منقضی یا نامعتبر | 401 |
ERR_AUTH_002 |
کد OTP نامعتبر | 401 |
ERR_AUTH_003 |
کد OTP منقضی شده | 401 |
ERR_AUTH_004 |
تعداد تلاشهای OTP به حد مجاز رسیده | 429 |
ERR_AUTH_005 |
نام کاربری یا رمز عبور اشتباه | 401 |
ERR_AUTH_006 |
دسترسی ممنوع | 403 |
ERR_VALIDATION_001 |
ورودی نامعتبر | 422 |
ERR_VALIDATION_002 |
فیلد الزامی وارد نشده | 422 |
ERR_NOT_FOUND_001 |
منبع درخواستی یافت نشد | 404 |
ERR_CONFLICT_001 |
تداخل: منبع در حال استفاده | 409 |
ERR_FORBIDDEN_001 |
دسترسی به این منبع مجاز نیست | 403 |
ERR_PAYMENT_001 |
درگاه پرداخت در دسترس نیست | 503 |
ERR_PAYMENT_002 |
مبلغ پرداخت نامعتبر | 422 |
ERR_PAYMENT_003 |
وضعیت نوبت برای پرداخت مناسب نیست | 422 |
ERR_FILE_001 |
فرمت فایل مجاز نیست | 422 |
ERR_SMS_003 |
تمپلیت قبلاً ارسال شده | 422 |
ERR_SECRETARY_001 |
پلن فعلی اجازه منشی بیشتر نمیدهد | 422 |
ERR_RATE_LIMIT_001 |
درخواستهای زیاد، بعداً تلاش کنید | 429 |