fix fish variz name, dalilrad, sms, bale

docs/PAYMENT_RECEIPT_ALERTS.md

@@ -20,7 +20,15 @@
 
 ## متن و سابقه
 
-تگ‌های متن: `{amount_rial}` (ریال)، `{customer_name}`، `{customer_mobile}`، `{received_at}` (تاریخ و ساعت شمسی)، `{paid_date}` (تاریخ واریز شمسی)، `{receipt_number}`، `{revision_version}`، `{receipt_link}` و `{manager_name}`. نام خالی مشتری با «نام ثبت نشده» جایگزین می‌شود. قالب‌بندی اضافی یا دسترسی به ویژگی‌های شیء در تگ‌ها پذیرفته نمی‌شود.
+تگ‌های متن: `{amount_rial}` (ریال)، `{customer_name}`، `{customer_mobile}`، `{received_at}` (تاریخ و ساعت شمسی)، `{paid_date}` (تاریخ واریز شمسی)، `{receipt_number}`، `{revision_version}`، `{receipt_link}` و `{manager_name}`. تگ `{customer_name}` شامل نام مشتری و نام واریزکننده ثبت‌شده روی نسخه فیش است؛ اگر این دو نام یکسان باشند، فقط یک بار نوشته می‌شود. اگر نام مشتری خالی باشد، نام واریزکننده نمایش داده می‌شود. در قالب سفارشی بدون این تگ نیز هویت مشتری/واریزکننده به متن اضافه می‌شود. نام‌ها با قواعد یکسان‌سازی فارسی مقایسه می‌شوند. قالب‌بندی اضافی یا دسترسی به ویژگی‌های شیء در تگ‌ها پذیرفته نمی‌شود.
+
+## نام واریزکننده و رد فیش
+
+فیلد «نام واریزکننده» در تمام مسیرهای ثبت و اصلاح فیش اجباری است. نام پروفایل مشتری (و در نبود آن، نام حساب کاربری) پیش‌فرض فرم است و قابل تغییر می‌ماند؛ ثبت این نام، پروفایل مشتری را تغییر نمی‌دهد. هر نسخه نام مستقل دارد. migration `payments.0008_paymentreceiptrevision_depositor_name` برای نسخه‌های قدیمی مقدار خالی می‌گذارد، چون نام واقعی واریزکننده قابل بازسازی نیست؛ پنل این وضعیت را مشخص می‌کند و هنگام اصلاح، ثبت نام الزامی است.
+
+پس از رد فیش توسط تأییدکننده مجاز، یک پیامک مشتری با رویداد `PAYMENT_RECEIPT_REJECTED` در صف موجود ثبت می‌شود. پیش از ثبت، صفحه بررسی هشدار می‌دهد که دلیل رد برای مشتری ارسال می‌شود و تأیید کارشناس را با نمایش متن دلیل می‌گیرد. درخواست HTTP بدون تأیید پذیرفته نمی‌شود. پیامک شامل دلیل کامل و لینک کوتاه مشاهده و اصلاح فیش است؛ کلید یکتای چرخه بررسی جلوی ساخت پیامک تکراری را می‌گیرد. ثبت تصمیم و صف در یک تراکنش انجام می‌شود و ارسال شبکه‌ای در Worker است.
+
+migrationهای `notifications.0019` و `notifications.0020` رویداد و قالب عمومی قابل ویرایش آن را اضافه می‌کنند. تگ `{rejection_reason}` متن دلیل است؛ اگر قالب سفارشی آن را حذف کند، دلیل همچنان به انتهای پیام اضافه می‌شود. پس از انتشار، migrationها را اجرا و Worker موجود را بازراه‌اندازی کنید.
 
 بله فایل خصوصی را مستقیماً همراه متن دریافت می‌کند؛ آدرس عمومی تصویر ایجاد نمی‌شود. لینک پیش‌فرض متن به جزئیات محافظت‌شده کارشناسان است. PNG/JPEG به‌صورت تصویر و دیگر فرمت‌های مجاز فیش به‌صورت فایل تصویری ارسال می‌شوند.
 

docs/PAYMENT_RECEIPT_CUSTOMER_DETAILS_QA.md

@@ -0,0 +1,27 @@
+# ارزیابی نام واریزکننده و پیامک رد فیش
+
+تاریخ ارزیابی: ۱۹ مهر ۱۴۰۵ (۲۰۲۶-۱۰-۱۱)
+
+## رفتار پیاده‌شده
+
+- تمام فرم‌های ثبت و اصلاح فیش، نام واریزکننده اجباری و قابل ویرایش دارند. نام از پروفایل مشتری یا نام حساب پر می‌شود؛ 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های قبلی و تغییرات موجود کاربر حفظ شدند. برای فیش‌های قدیمی نام واقعی واریزکننده جعل یا از پروفایل بازسازی نمی‌شود؛ وضعیت ثبت نشدن نام در پنل مشخص است.