28 lines
4.8 KiB
Markdown
28 lines
4.8 KiB
Markdown
# ارزیابی نام واریزکننده و پیامک رد فیش
|
|
|
|
تاریخ ارزیابی: ۱۹ مهر ۱۴۰۵ (۲۰۲۶-۱۰-۱۱)
|
|
|
|
## رفتار پیاده‌شده
|
|
|
|
- تمام فرم‌های ثبت و اصلاح فیش، نام واریزکننده اجباری و قابل ویرایش دارند. نام از پروفایل مشتری یا نام حساب پر می‌شود؛ POST بدون نام حتی با وجود نام در پروفایل رد می‌شود.
|
|
- نام روی نسخه فیش ذخیره می‌شود و اصلاح آن، نام نسخه قبلی و پروفایل مشتری را تغییر نمی‌دهد. نام مشتری و نام واریزکننده در میزکار و جزئیات کارکنان نمایش داده می‌شوند.
|
|
- اعلان ثبت فیش در پیامک مدیران و بله هر دو نام متفاوت را نمایش می‌دهد؛ نام یکسان پس از یکسان‌سازی حروف و فاصله‌ها فقط یک بار می‌آید. اطلاعات اعلان snapshot زمان ثبت نسخه است.
|
|
- رد فیش با دلیل و تأیید صریح کارشناس انجام می‌شود. انصراف از دیالوگ، فرم و دکمه‌ها را قابل استفاده نگه می‌دارد. کنترل مجوز پیش از کنترل تأیید انجام می‌شود.
|
|
- پیامک رد در تراکنش تصمیم و با کلید یکتای چرخه بررسی ساخته می‌شود؛ ارسال از Worker موجود انجام می‌شود. دلیل کامل حتی در قالب سفارشی بدون تگ دلیل به مشتری می‌رسد.
|
|
- هشدار قرمز بانک شناسه‌دار، نام بانک و شناسه اختصاصی تولیدشده با الگوریتم موجود را نمایش می‌دهد و با تغییر حساب مقصد به‌روز می‌شود. الزام واردکردن شناسه در خود عملیات بانکی توضیح داده می‌شود؛ فیلد اختیاری شناسه درج‌شده روی فیش مطابق قرارداد فعلی حفظ شده است.
|
|
|
|
## نتایج بررسی
|
|
|
|
- کل تست‌های سمت سرور: ۵۱۴ موفق، ۷ ردشده از اجرا به علت نیاز به PostgreSQL؛ محیط فعلی SQLite است.
|
|
- تست‌های مرورگری پرداخت: ۴۱ سناریوی متمایز موفق، شامل تست نسخه‌گذاری PWA. یک خطای واقعی قفل شدن دکمه پس از انصراف کشف، اصلاح و دوباره تست شد.
|
|
- ۱۶ تست جدید سمت سرور و ۶ سناریوی جدید مرورگری برای نام، هشدار بانک و تأیید رد اضافه شدند.
|
|
- تست‌های ارسال، درگاه پیامک و بله را mock می‌کنند و پیامی به مشتری یا گروه واقعی نمی‌فرستند.
|
|
- `manage.py check` بدون اشکال؛ `makemigrations --check --dry-run` بدون تغییر جامانده؛ بررسی whitespace فایل‌های این تغییر بدون خطا.
|
|
- `PROJECT_TREE.txt`، تست‌های موجود و مستندات اعلان بررسی شدند. Graphify برای ارتباط مستندات و بخش‌ها و Ripwire برای impact، uses، قرارداد و دروازه تست به کار رفتند.
|
|
- Ripwire پس از بازخوانی بدون کش یک هشدار عمده باقی‌مانده دارد: افزایش تعداد پارامترهای `decide_receipt` به دلیل پارامتر اختیاری تأیید رد. این تغییر عمدی است؛ بررسی قرارداد هیچ فراخوان ناسازگاری گزارش نکرد و تست‌های مجوز و تصمیم موفق بودند. یافته‌های عدم پوشش AST، جایگزین نتایج اجرای تست نیستند.
|
|
- محتوای واقعی `/chaharsu/payment-receipt/` و `/staff/payments/` و فایل‌های JavaScript سرو‌شده روی سرور محلی بررسی شدند. دقیقاً یک شنونده روی `0.0.0.0:8000` وجود دارد. UUIDهای نمونه درخواست در دیتابیس محلی نبودند؛ صفحات جزئیات با داده مستقل در live_server تست شدند.
|
|
|
|
## انتشار
|
|
|
|
روی دیتابیس توسعه، پس از backup، migrationهای `payments.0008`، `notifications.0019` و `notifications.0020` اجرا شدند. برای محیط اصلی نیز migrationها باید اجرا و Worker `process_notifications` با کد جدید بازراه‌اندازی شود. migrationهای قبلی و تغییرات موجود کاربر حفظ شدند. برای فیش‌های قدیمی نام واقعی واریزکننده جعل یا از پروفایل بازسازی نمی‌شود؛ وضعیت ثبت نشدن نام در پنل مشخص است.
|