# ارزیابی نام واریزکننده و پیامک رد فیش

تاریخ ارزیابی: ۱۹ مهر ۱۴۰۵ (۲۰۲۶-۱۰-۱۱)

## رفتار پیاده‌شده

- تمام فرم‌های ثبت و اصلاح فیش، نام واریزکننده اجباری و قابل ویرایش دارند. نام از پروفایل مشتری یا نام حساب پر می‌شود؛ 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های قبلی و تغییرات موجود کاربر حفظ شدند. برای فیش‌های قدیمی نام واقعی واریزکننده جعل یا از پروفایل بازسازی نمی‌شود؛ وضعیت ثبت نشدن نام در پنل مشخص است.