70 lines
5.6 KiB
Markdown
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 مرورگر پروژه، در عرضهای ۱۴۴۰، ۳۹۰ و ۳۲۰ اجرا میشوند.
|