delete option staff varizi

docs/PAYMENT_NOTICE_DELETION.md

@@ -0,0 +1,19 @@
+# حذف اعلامیه بدون فیش
+
+در جزئیات اعلامیه پنل staff، ایجادکننده، مدیرعامل (`CEO`)، مدیرکل (`GENERAL_ADMIN`) و superuser فعال می‌توانند اعلامیه فاقد فیش را حذف کنند. حساب و پروفایل کارشناس باید فعال باشند. مجوزهای ایجاد یا تأیید پرداخت به‌تنهایی مجوز حذف نمی‌دهند.
+
+بخش «حذف اعلامیه واریز» ابتدا هشدار را باز می‌کند. ارسال فرم به تأیید صریح checkbox، POST و CSRF نیاز دارد. وجود هر فیش مرتبط، در هر وضعیت از جمله ردشده، حذف را ممنوع می‌کند. فیش مستقلِ بدون ارتباط به اعلامیه مانع حذف نیست.
+
+حذف منطقی با `deleted_at` انجام می‌شود و `cancelled_at` نیز تنظیم می‌شود. سوابق مالی، پیامک و لینک‌های صادرشده برای ممیزی نگهداری می‌شوند؛ اعلامیه از فهرست‌ها و صفحات مشتری و staff خارج می‌شود و لینک‌ها و نشست‌های مربوط دیگر معتبر نیستند. رویداد `NOTICE_DELETED` مشخصات اعلامیه و عامل حذف را نگه می‌دارد. بازیابی از پنل ارائه نشده است.
+
+سرویس حذف نقش فعلی عامل را مجدداً از دیتابیس می‌خواند و مانند ثبت فیش، ابتدا مشتری و سپس اعلامیه را قفل می‌کند. در نتیجه ثبت هم‌زمان فیش مرتبط و حذف نمی‌توانند هر دو موفق شوند. قفل لینک در سرویس حذف گرفته نمی‌شود تا با ترتیب قفل‌های ارسال فیش ناشناس تداخل نداشته باشد. فرم‌های ثبت فیشِ بازمانده از قبل از حذف نیز در سرور رد می‌شوند.
+
+پیامک‌های PENDING، RETRYING و FAILED لغو می‌شوند. worker پیش از پردازش پیامک صدور اعلامیه، حذف را دوباره بررسی می‌کند؛ پیامکی که قبلاً به ارائه‌دهنده تحویل داده شده قابل بازگرداندن نیست، اما لینک آن نامعتبر می‌شود.
+
+تست‌های دائمی:
+
+```bash
+.venv/Scripts/python.exe -m pytest tests/test_payment_notice_deletion.py tests/test_payment_notice_concurrency.py tests/e2e/test_notice_deletion_e2e.py -q
+```
+
+تست هم‌زمانی فقط با دیتابیس تست PostgreSQL اجرا می‌شود؛ SQLite صحت قفل ردیف را اثبات نمی‌کند. تست‌های دیگر و مرورگر از دیتابیس جداگانه و provider ساختگی استفاده می‌کنند و پیامک واقعی نمی‌فرستند.