estelam ticket, varizha , others
This commit is contained in:
1 parent
35a1ec1794
commit
6b546aad76
71 files changed
+2865
-191
No files matched your search
@@ -0,0 +1,69 @@
|
||||
# بازگشایی پاسخهای ارسال گروهی
|
||||
|
||||
ارسالهای جدید پیشفرض بازگشایی یکجا دارند. ارسالهای قدیمی بدون رکورد
|
||||
`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 مرورگر پروژه، در عرضهای ۱۴۴۰، ۳۹۰ و ۳۲۰ اجرا میشوند.
|
||||
@@ -1,6 +1,8 @@
|
||||
# اطلاعرسانی فیش مشتری
|
||||
|
||||
پس از ثبت موفق فیش مشتری، اپ `payments` اعلانها را در صف `NotificationJob` قرار میدهد. ثبت از حساب مشتری و لینک کوتاه پرداخت هر دو پشتیبانی میشوند. فیشی که کارشناس به نمایندگی از مشتری ثبت میکند اعلان ندارد. تصویر هر نسخه مستقل است؛ گزینه «اطلاعرسانی فیش اصلاحشده مشتری» تعیین میکند نسخههای اصلاحی نیز اعلان داشته باشند.
|
||||
پس از ثبت موفق فیش مشتری، اپ `payments` اعلانها را در صف `NotificationJob` قرار میدهد. ثبت از حساب مشتری، لینک کوتاه پرداخت و «ثبت فیش برای مشتری» در پنل کارشناس همگی پشتیبانی میشوند. ثبت دستی کارشناس نیز با همان تنظیمات به مدیران فعال پیامک میفرستد و تصویر فیش را به همان گروه بله ارسال میکند؛ اطلاعات پیام مربوط به مشتری و واریزکننده است. تصویر هر نسخه مستقل است؛ گزینه «اطلاعرسانی فیش اصلاحشده مشتری» تعیین میکند نسخههای اصلاحی نیز، چه توسط مشتری و چه کارشناس مجاز ثبت شوند، اعلان داشته باشند.
|
||||
|
||||
این اصلاح migration یا تنظیمات جداگانه نمیخواهد. برای اعمال آن، سرور برنامه و Worker موجود `process_notifications` را با نسخه جدید کد بازراهاندازی کنید. اعلانهای مربوط به ثبتهای قبلی که صفی برای آنها ساخته نشده، بهصورت خودکار ارسال نمیشوند.
|
||||
|
||||
## راهاندازی
|
||||
|
||||
|
||||
Reference in new issue
Block a user