feat: implement doctor import completion feature and crawler enhancements
- Added the remaining components for the doctor import feature in the backend, including role management, ownership transfer endpoint, and captcha bypass for crawler service login. - Created detailed scenarios for the doctor claim process, ensuring proper identity verification and mobile validation. - Established a crawler interface for token management and state tracking using SQLite, enabling a resume capability for the crawling process.
This commit is contained in:
hamed
@@ -0,0 +1,346 @@
|
||||
حتماً، متن کامل پرامپت را در محیط قابل کپی میگذارم:
|
||||
|
||||
یک قابلیت کامل برای Claim Doctor Profile یا «احراز مالکیت پروفایل پزشک» در سیستم Clinic Pro و سایت نوبت 724 پیادهسازی کن.
|
||||
|
||||
قبل از هرگونه تغییر، ابتدا ساختار فعلی Backend و Frontend را کامل بررسی کن و مشخص کن وضعیت پزشکان ایمپورتشده در حال حاضر چگونه مدیریت میشود.
|
||||
|
||||
در سیستم، پزشک ایمپورتشده میتواند یکی از وضعیتهای زیر را داشته باشد:
|
||||
|
||||
- unclaimed
|
||||
- pending_transform
|
||||
- claimed
|
||||
|
||||
نام دقیق enum، field و statusهای موجود در پروژه را بررسی کن و بدون ایجاد ساختار تکراری، از معماری فعلی استفاده کن.
|
||||
|
||||
سناریوی اصلی
|
||||
|
||||
زمانی که یک پزشک از دیتای سازمان نظام پزشکی Import میشود و هنوز به کاربر یا پزشک واقعی در Clinic Pro متصل نشده است، وضعیت آن باید unclaimed باشد.
|
||||
|
||||
تا زمانی که پروفایل پزشک Claim نشده است:
|
||||
|
||||
- نوبتدهی آنلاین پزشک باید غیرفعال باشد.
|
||||
- در سایت اصلی نوبت 724 و تمام سایتهای زیرمجموعه و دامنههای نمایندگان، وضعیت پروفایل باید مشخص باشد.
|
||||
- کاربر باید متوجه شود که این پروفایل هنوز توسط پزشک تأیید و مدیریت نشده است.
|
||||
|
||||
در صفحه پروفایل پزشک، دقیقاً زیر بخش «نوبتدهی»، یک بخش برای احراز مالکیت پروفایل نمایش داده شود.
|
||||
|
||||
متن مناسب فارسی مانند زیر نمایش داده شود:
|
||||
|
||||
«آیا شما این پزشک هستید؟»
|
||||
|
||||
و یک دکمه با عنوان:
|
||||
|
||||
«تأیید و مدیریت این پروفایل»
|
||||
|
||||
این بخش فقط برای پزشکانی نمایش داده شود که وضعیت آنها unclaimed است.
|
||||
|
||||
Modal احراز مالکیت پروفایل
|
||||
|
||||
با کلیک روی دکمه، یک Modal باز شود.
|
||||
|
||||
فرم باید با UI فعلی پروژه، RTL، فارسی و کاملاً Responsive طراحی شود.
|
||||
|
||||
اطلاعات موردنیاز فرم:
|
||||
|
||||
- شماره موبایل
|
||||
- کد ملی
|
||||
- تاریخ تولد به شمسی
|
||||
- نام
|
||||
- نام خانوادگی
|
||||
|
||||
ارتباط با API.ir
|
||||
|
||||
تمام فرآیند احراز هویت باید از Backend انجام شود.
|
||||
|
||||
هیچ Request مستقیمی از Frontend به API.ir ارسال نشود.
|
||||
|
||||
Token مربوط به API.ir باید در Environment Variable نگهداری شود و هرگز به Frontend ارسال نشود.
|
||||
|
||||
از API زیر برای دریافت اطلاعات هویتی شخص استفاده کن:
|
||||
|
||||
curl https://s.api.ir/api/sw1/PersonInfo
|
||||
–request POST
|
||||
–header ‘Content-Type: application/json’
|
||||
–header ‘Authorization: Bearer [API_TOKEN]’
|
||||
–data ‘{
|
||||
“nationalCode”: “0010007700”,
|
||||
“birthDate”: “1371/1/1”
|
||||
}’
|
||||
|
||||
نمونه Response:
|
||||
|
||||
{
|
||||
“data”: {
|
||||
“nationalCode”: “0010007700”,
|
||||
“firstName”: “محسن”,
|
||||
“lastName”: “اکبری”,
|
||||
“fatherName”: “علی”,
|
||||
“gender”: 1,
|
||||
“alive”: true
|
||||
},
|
||||
“success”: false,
|
||||
“code”: 0,
|
||||
“message”: null
|
||||
}
|
||||
|
||||
طبق نمونه API، ورودی PersonInfo شامل nationalCode و birthDate است.
|
||||
|
||||
ابتدا بررسی کن که آیا API.ir Endpoint دیگری برای تطبیق شماره موبایل و کد ملی دارد یا خیر.
|
||||
|
||||
اگر چنین Endpointی در ساختار فعلی پروژه یا مستندات موجود تعریف شده است، از آن برای تأیید مالکیت شماره موبایل استفاده کن.
|
||||
|
||||
در غیر این صورت، شماره موبایل باید با OTP تأیید شود.
|
||||
|
||||
OTP بهتنهایی به معنی مالکیت پروفایل پزشک نیست.
|
||||
|
||||
Claim فقط زمانی موفق باشد که هویت شخص با اطلاعات پزشک Importشده تطبیق داده شده باشد.
|
||||
|
||||
فرآیند احراز هویت
|
||||
|
||||
کاربر فرم را تکمیل و ارسال میکند.
|
||||
|
||||
Backend باید اطلاعات را دریافت و Validation کند.
|
||||
|
||||
سپس با استفاده از nationalCode و birthDate به API.ir درخواست PersonInfo ارسال شود.
|
||||
|
||||
اطلاعات برگشتی شامل موارد زیر بررسی شود:
|
||||
|
||||
- nationalCode
|
||||
- firstName
|
||||
- lastName
|
||||
- alive
|
||||
|
||||
اگر alive برابر false بود، فرآیند Claim متوقف شود.
|
||||
|
||||
نام و نام خانوادگی برگشتی از API.ir باید با اطلاعات پزشک Importشده از سازمان نظام پزشکی مقایسه شود.
|
||||
|
||||
همچنین نام و نام خانوادگی واردشده توسط کاربر باید با اطلاعات تأییدشده مقایسه شود.
|
||||
|
||||
قبل از Compare نامهای فارسی، عملیات Normalize انجام شود.
|
||||
|
||||
موارد زیر مدیریت شوند:
|
||||
|
||||
- تفاوت ي و ی
|
||||
- تفاوت ك و ک
|
||||
- فاصلههای اضافه
|
||||
- نیمفاصله
|
||||
- فاصله ابتدا و انتهای متن
|
||||
- Unicode normalization
|
||||
|
||||
از Compare ساده و مستقیم String استفاده نکن.
|
||||
|
||||
در صورت امکان، یک Service مشترک برای Persian Name Normalization ایجاد یا از Service موجود استفاده کن.
|
||||
|
||||
تأیید شماره موبایل
|
||||
|
||||
شماره موبایل کاربر باید تأیید شود.
|
||||
|
||||
اگر API.ir امکان تطبیق شماره موبایل با کد ملی را دارد، از همان API استفاده کن.
|
||||
|
||||
در غیر این صورت، از OTP موجود در سیستم استفاده کن.
|
||||
|
||||
اگر سیستم در حال حاضر OTP Service دارد، Service جدید و تکراری ایجاد نکن.
|
||||
|
||||
از زیرساخت فعلی Authentication و OTP استفاده کن.
|
||||
|
||||
پس از تأیید OTP، شماره موبایل Verified در نظر گرفته شود.
|
||||
|
||||
اما Claim نهایی فقط بعد از موفقیت احراز هویت PersonInfo انجام شود.
|
||||
|
||||
اتصال پروفایل پزشک به کاربر
|
||||
|
||||
اگر احراز هویت موفق بود:
|
||||
|
||||
- User مربوط به پزشک را بر اساس معماری فعلی سیستم پیدا کن.
|
||||
- اگر Flow فعلی سیستم اجازه ایجاد User را میدهد، User مناسب ایجاد شود.
|
||||
- پروفایل Doctor ایمپورتشده به User مربوطه متصل شود.
|
||||
- وضعیت Doctor از unclaimed به claimed تغییر کند.
|
||||
- زمان Claim ذخیره شود.
|
||||
- روش احراز هویت ذخیره شود.
|
||||
- در صورت وجود Audit Log، عملیات Claim ثبت شود.
|
||||
- از Claim مجدد Doctor جلوگیری شود.
|
||||
|
||||
تمام عملیات نهایی Claim باید داخل Transaction انجام شود.
|
||||
|
||||
اگر سیستم فعلی از وضعیت pending_transform در این Flow استفاده میکند، ابتدا منطق آن را بررسی کن.
|
||||
|
||||
مشخص کن pending_transform دقیقاً در چه شرایطی استفاده میشود و Flow جدید را با همان معماری هماهنگ کن.
|
||||
|
||||
Status جدید و تکراری ایجاد نکن مگر اینکه واقعاً ضروری باشد.
|
||||
|
||||
جلوگیری از Race Condition
|
||||
|
||||
ممکن است دو Request همزمان برای Claim یک Doctor ارسال شوند.
|
||||
|
||||
Backend باید از Race Condition جلوگیری کند.
|
||||
|
||||
قبل از نهایی کردن Claim، وضعیت Doctor مجدداً بررسی شود.
|
||||
|
||||
در صورت نیاز از Transaction، Database Lock یا مکانیزم مناسب معماری فعلی استفاده کن.
|
||||
|
||||
یک Doctor تحت هیچ شرایطی نباید به دو User مختلف متصل شود.
|
||||
|
||||
پیام موفقیت
|
||||
|
||||
بعد از Claim موفق، پیام خوشآمدگویی نمایش داده شود:
|
||||
|
||||
«دکتر [نام پزشک]، به نوبت 724 خوش آمدید 🎉
|
||||
|
||||
پروفایل شما با موفقیت تأیید شد و اکنون میتوانید اطلاعات پروفایل و تنظیمات نوبتدهی خود را مدیریت کنید.»
|
||||
|
||||
سپس کاربر بر اساس Flow فعلی Authentication سیستم به پنل مناسب هدایت شود.
|
||||
|
||||
مدیریت خطاها
|
||||
|
||||
برای حالتهای زیر Error Handling مناسب ایجاد کن:
|
||||
|
||||
- اطلاعات هویتی اشتباه است.
|
||||
- تاریخ تولد اشتباه است.
|
||||
- نام شخص با پزشک تطبیق ندارد.
|
||||
- کد ملی نامعتبر است.
|
||||
- شماره موبایل تأیید نشده است.
|
||||
- OTP نامعتبر یا منقضی شده است.
|
||||
- API.ir در دسترس نیست.
|
||||
- API.ir Timeout شده است.
|
||||
- Response API نامعتبر است.
|
||||
- Doctor قبلاً Claim شده است.
|
||||
- Doctor در وضعیت قابل Claim نیست.
|
||||
- User دیگری همزمان Doctor را Claim کرده است.
|
||||
- Rate Limit رد شده است.
|
||||
|
||||
پیامهای Frontend باید فارسی، واضح و قابل فهم باشند.
|
||||
|
||||
اطلاعات حساس API یا جزئیات Internal Error در Frontend نمایش داده نشود.
|
||||
|
||||
امنیت
|
||||
|
||||
Endpoint مربوط به Claim باید Rate Limit داشته باشد.
|
||||
|
||||
برای جلوگیری از Brute Force، محدودیت تعداد تلاش بر اساس موارد مناسب مانند موارد زیر اعمال شود:
|
||||
|
||||
- IP
|
||||
- Doctor ID
|
||||
- National Code Hash
|
||||
- User ID
|
||||
- Mobile Number Hash
|
||||
|
||||
کد ملی و تاریخ تولد را در Logهای معمولی بهصورت Plain Text ثبت نکن.
|
||||
|
||||
شماره موبایل کامل را در Log ثبت نکن.
|
||||
|
||||
API Token را Log نکن.
|
||||
|
||||
Request و Response کامل API.ir را در Production Log ذخیره نکن.
|
||||
|
||||
در صورت نیاز برای Audit، فقط اطلاعات ضروری و Mask شده ذخیره شود.
|
||||
|
||||
در صورت وجود CAPTCHA یا ALTCHA در پروژه، بررسی کن که Claim Endpoint باید تحت محافظت ALTCHA قرار بگیرد.
|
||||
|
||||
از زیرساخت فعلی ALTCHA استفاده کن و سیستم CAPTCHA جدید ایجاد نکن.
|
||||
|
||||
Frontend
|
||||
|
||||
این قابلیت باید در موارد زیر کار کند:
|
||||
|
||||
- سایت اصلی نوبت 724
|
||||
- تمام دامنههای زیرمجموعه
|
||||
- سایتهای نمایندگان
|
||||
|
||||
از Component مشترک استفاده کن.
|
||||
|
||||
منطق Claim را برای هر Domain جداگانه Duplicate نکن.
|
||||
|
||||
Tenant و Domain Logic فعلی پروژه را بررسی کن و از همان ساختار استفاده کن.
|
||||
|
||||
UI باید با Design System فعلی پروژه هماهنگ باشد.
|
||||
|
||||
Modal باید:
|
||||
|
||||
- RTL باشد.
|
||||
- فارسی باشد.
|
||||
- Responsive باشد.
|
||||
- روی موبایل UX مناسبی داشته باشد.
|
||||
- Loading State داشته باشد.
|
||||
- Error State داشته باشد.
|
||||
- Success State داشته باشد.
|
||||
- از Double Submit جلوگیری کند.
|
||||
|
||||
برای تاریخ تولد از Date Picker شمسی موجود در پروژه استفاده کن.
|
||||
|
||||
Library جدید برای تاریخ شمسی نصب نکن، مگر اینکه پروژه هیچ راهکار فعلی برای تاریخ شمسی نداشته باشد.
|
||||
|
||||
تست
|
||||
|
||||
تستهای Backend و Frontend لازم را اضافه کن.
|
||||
|
||||
حداقل سناریوهای زیر تست شوند:
|
||||
|
||||
- Claim موفق
|
||||
- کد ملی اشتباه
|
||||
- تاریخ تولد اشتباه
|
||||
- عدم تطبیق نام پزشک
|
||||
- Doctor قبلاً Claim شده
|
||||
- Doctor با Status غیرمجاز
|
||||
- API.ir Timeout
|
||||
- API.ir Error
|
||||
- Response نامعتبر API
|
||||
- تلاش همزمان برای Claim یک Doctor
|
||||
- Normalize صحیح نام فارسی
|
||||
- OTP نامعتبر
|
||||
- OTP منقضیشده
|
||||
- Rate Limit
|
||||
- نمایش Claim Form فقط برای unclaimed
|
||||
- عدم نمایش Claim Form برای claimed
|
||||
- عدم امکان Claim یک Doctor توسط دو User
|
||||
|
||||
API.ir را در تستها Mock کن.
|
||||
|
||||
تستها تحت هیچ شرایطی نباید به سرویس واقعی API.ir Request ارسال کنند.
|
||||
|
||||
خروجی مورد انتظار
|
||||
|
||||
قابلیت Claim Doctor Profile را بهصورت End-to-End پیادهسازی کن.
|
||||
|
||||
ابتدا معماری موجود پروژه را کامل بررسی کن.
|
||||
|
||||
سپس موارد زیر را پیادهسازی کن:
|
||||
|
||||
- Backend Claim Flow
|
||||
- API.ir Integration
|
||||
- Identity Verification
|
||||
- Mobile Verification
|
||||
- OTP Integration
|
||||
- Security
|
||||
- Rate Limiting
|
||||
- Doctor/User Relation
|
||||
- Transaction Handling
|
||||
- Race Condition Protection
|
||||
- Frontend Claim Section
|
||||
- Claim Modal
|
||||
- Success Flow
|
||||
- Error Handling
|
||||
- Tests
|
||||
|
||||
از ایجاد کد تکراری یا معماری موازی خودداری کن.
|
||||
|
||||
در پایان گزارشی ارائه بده که شامل موارد زیر باشد:
|
||||
|
||||
- فایلهای تغییرکرده
|
||||
- Flow نهایی Claim
|
||||
- نحوه ارتباط با API.ir
|
||||
- نحوه تطبیق هویت
|
||||
- نحوه تأیید شماره موبایل
|
||||
- نحوه اتصال Doctor به User
|
||||
- کاربرد دقیق pending_transform در Flow
|
||||
- تغییرات Database
|
||||
- Environment Variableهای جدید
|
||||
- تستهای اضافهشده
|
||||
- نکات امنیتی پیادهسازیشده
|
||||
|
||||
مهم:
|
||||
|
||||
بدون بررسی کد فعلی پروژه، درباره Entityها، Tableها، Fieldها، Routeها، Authentication Flow، OTP Service یا معماری سیستم فرض نساز.
|
||||
|
||||
ابتدا ساختار موجود را بررسی کن و قابلیت را کاملاً با معماری فعلی پروژه هماهنگ کن.
|
||||
|
||||
اگر خواستی، نسخه مخصوص Claude Code / Cursor Agent همین پرامپت را هم با دستورهای اجرایی دقیقتر برات تنظیم میکنم.
|
||||
Reference in New Issue
Block a user