Files
customerTicket/docs/DISPATCH_RESPONSE_OPENING.md

70 lines
5.6 KiB
Markdown

# بازگشایی پاسخ‌های ارسال گروهی
ارسال‌های جدید پیش‌فرض بازگشایی یکجا دارند. ارسال‌های قدیمی بدون رکورد
`DispatchResponseControl` رفتار قبلی را حفظ می‌کنند و پیامک بازگشایی ندارند.
در حالت یکجا، کارکنان و superuser تا بازگشایی متن، پیوست و تاریخچهٔ پاسخ
مخاطب را نمی‌بینند. مخاطب به پاسخ خودش دسترسی دارد.
## مجوزها در Django Admin
- مشاهدهٔ همه ارسال‌های گروهی: `tickets.view_all_bulk_dispatches`
- مشاهدهٔ همه استعلام‌ها: `tickets.view_all_inquiries`
- بازگشایی همه ارسال‌های قابل مشاهده: `tickets.open_all_dispatch_responses`
مجوز بازگشایی به‌تنهایی مجوز مشاهده ایجاد نمی‌کند. ایجادکنندهٔ ارسال خودش
می‌تواند بازگشایی کند. حساب باید فعال باشد؛ کاربران پنل staff با پروفایل
غیرفعال مجاز نیستند. عنوان شغلی یا نقش جدیدی به‌صورت خودکار مجوز نمی‌گیرد.
## پیامک
رویداد `DISPATCH_RESPONSES_OPENED` در SMSTemplate قابل ویرایش است؛ قالب
اختصاصی واحد بر قالب عمومی اولویت دارد. این رویداد تگ جایگزین ندارد.
متن دقیق هنگام تأیید ثبت می‌شود و تغییر بعدی قالب بر پیامک‌های صف‌شده اثر
نمی‌گذارد. تغییر قالب میان پیش‌نمایش و تأیید، نیاز به بررسی دوباره دارد.
فقط پاسخ‌دهندگان با پاسخ حذف‌نشده در لحظهٔ بازگشایی در صف پیامک قرار
می‌گیرند. پاسخ صرفاً دارای پیوست نیز معتبر است. سقف ۱۵ بر اساس گیرندگان
واجد شرایط هنگام ایجاد است و با تغییر بعدی گروه عوض نمی‌شود. حالت
جداگانه و ارسال بیش از ۱۵ گیرنده پیامک بازگشایی ندارند.
بازگشایی یک‌بار است. پاسخ و ویرایش بعدی فوراً برای کاربران مجاز قابل مشاهده
است و پیامک بازگشایی دیگری ایجاد نمی‌کند. بازگشایی با رسیدِ خواندن پیام
تفاوت دارد. صف و تحویل پیامک نیز جدا از بازگشایی گزارش می‌شوند.
اعلان پاسخ ارسال‌های جدید در بله، با اطلاعات وضعیت و لینک پنل، به مقصد
خصوصی بلهٔ ایجادکننده ارسال می‌شود؛ تنظیم مقصد و فعال بودن اعلان در پروفایل
کارشناس لازم است. متن پیشنهاد در اعلان قرار نمی‌گیرد. اعلان‌های تیکت‌های
عادی و ارسال‌های قدیمی مسیر موجود خود را حفظ می‌کنند.
## انتشار و migration
1. از دیتابیس production پشتیبان قابل بازیابی بگیرید و migrationها را ابتدا
روی کپی آزمایشی بررسی کنید. این تغییر production را خودکار migrate نمی‌کند.
2. migrationهای جدید: `tickets.0018_dispatch_response_opening` و
`notifications.0021_dispatch_response_opening`. اولی جدول جدید می‌سازد؛
دومی choices را فقط در وضعیت Django تغییر می‌دهد و قالب مفقود را با
`get_or_create` اضافه می‌کند. رکورد یا قالب قبلی بازنویسی نمی‌شود.
3. کد برنامه و worker را هماهنگ منتشر و worker پیامک را با نسخهٔ جدید
راه‌اندازی مجدد کنید؛ worker قدیمی رویداد تازه را نمی‌شناسد.
4. تنظیم جدید Nginx برای `/protected-media/dispatch-responses/` را نیز منتشر
کنید. فایل‌های این مسیر فقط از endpoint مجاز برنامه تحویل داده می‌شوند.
فایل‌های قبلی جابه‌جا نمی‌شوند.
5. مجوز مشاهده و بازگشایی را فقط به کاربران منتخب بدهید. هیچ مجوزی قفل
پاسخ را دور نمی‌زند. تنظیمات و سابقه بازگشایی در Admin فقط خواندنی‌اند.
پس از استفادهٔ قابلیت، rollback جدول کنترل پاسخ ممنوع است تا محرمانگی و
سابقه بازگشایی حذف نشود. بازگشت به کد قدیمی نیز قفل جدید را نمی‌شناسد؛ برای
بازگشت از نسخه، از برنامهٔ بازیابی هماهنگ کد و دیتابیس استفاده کنید.
این محدودیت در برنامه و Django Admin اعمال می‌شود؛ دسترسی مستقیم مدیر
زیرساخت به دیتابیس یا فایل سرور، رمزنگاری نشده است.
## تست‌ها
`tests/test_dispatch_response_opening.py` دسترسی، پیوست، Admin، قالب، سقف
مخاطب، تراکنش صف و worker را بررسی می‌کند.
`tests/test_dispatch_opening_postgres.py` هم‌زمانی واقعی و حفظ داده در
migration را بررسی می‌کند. تست‌های هم‌زمانی باید روی PostgreSQL اجرا شوند.
سناریوهای رابط کاربری در `tests/e2e/test_dispatch_response_opening_e2e.py`
با fixture مرورگر پروژه، در عرض‌های ۱۴۴۰، ۳۹۰ و ۳۲۰ اجرا می‌شوند.