improve bazdid 3

docs/visit_hold_entezar.md

@@ -104,7 +104,7 @@
 | کنترل | تقویم شمسی (همان `pDatepicker` پروژه) |
 | پیش‌فرض | اگر خالی بماند و تیک «انجام شد» زده شود ⇒ **+۱۴ روز** |
 | سقف | **۶ ماه** (اعتبارسنجی سروری) |
-| حالت ویرایش | فیلد با نوع اقدام هم‌راستا می‌شود (نمایش/پنهان) |
+| حالت ویرایش | فیلد با نوع اقدام هم‌راستا می‌شود (نمایش/پنهان) **و مقدار ذخیره‌شدهٔ مشتری در آن بارگذاری می‌شود** |
 
 نکتهٔ مهم: فیلد «تاریخ و ساعتی که کار باید انجام شود» (`dateTimeAnjam`) همچنان
 «زمان تماس» است و دست نخورده باقی می‌ماند. دو مفهوم، دو فیلد.
@@ -177,6 +177,30 @@
   اما کادر هشدار برای هماهنگیِ انجام‌شده به‌صورت اطلاعاتی نمایش داده می‌شود.
 * **باز شدن مجدد مودال**: تیک، هشدار و وضعیت تأیید همیشه ریست می‌شوند.
 
+#### بارگذاری مقدار ذخیره‌شده در حالت ویرایش
+
+هر ردیف اقدام، مقدار فعلی `Customer.visit_hold_until` را به‌صورت ISO در
+صفت `customer_hold` نگه می‌دارد. هنگام کلیک روی ردیف (باز کردن فرم ویرایش)،
+تابع `seedHoldPicker()` آن را به تقویم شمسی و فیلد مخفی `visitHoldUntil`
+می‌نویسد.
+
+> **باگی که این بخش رفع می‌کند:** قبلاً فرم ویرایش مقدار را از دیتابیس
+> نمی‌خواند. مقدار در سرور **درست ذخیره می‌شد** ولی چون فیلد هنگام باز شدن
+> مجدد خالی نمایش داده می‌شد، کاربر فکر می‌کرد «ثبت نشده است».
+
+ترتیب کار مهم است: `seedHoldPicker()` **بعد از** `toggleCoordinationField()`
+صدا زده می‌شود، چون برای انواع غیرهماهنگی، `toggle` فیلد را پاک می‌کند.
+
+#### ایمنی ویرایش رکوردهای قدیمی
+
+در حالت **ویرایش**، تغییر نوع اقدام به غیرهماهنگی، قرار دستی را پاک
+**نمی‌کند**؛ زیرا رکورد ویرایش‌شده ممکن است قدیمی‌تر از یک هماهنگیِ جدیدتر
+باشد و پاک‌کردن، قرار معتبر را از بین می‌برد. اعتبارسنجی `manual_holds_map`
+(شرط «آخرین فعالیت = هماهنگی») خودش قرار را بی‌اثر می‌کند.
+
+در حالت **ایجاد** برعکس است: اقدام تازه آخرین فعالیت مشتری است، پس ثبت
+بازدید جدید قرار قبلی را پاک می‌کند.
+
 ### ۴.۳ راهنمای بازشونده (فقط «هماهنگی»)
 
 زیر فیلد تاریخ پیگیری، یک دکمهٔ راهنما با آیکون `!` قرار دارد که پنل توضیحات را
@@ -231,40 +255,51 @@ visit_hold_until = max(مقدار فعلی، تاریخ جدید)
 
 ## ۵. صفحهٔ انتظار: چهار گروه و فیلترها
 
-هر مشتری معوق **دقیقاً در یکی** از این چهار گروه است:
+تفکیک بر اساس **نوعِ منبع** است، نه «چند گروه ثابت». هر مشتری می‌تواند صفر تا
+سه منبع داشته باشد:
 
-| گروه | تعریف |
-|---|---|
-| **A** | معوق، بدون هیچ قرار |
-| **B** | معوق، فقط قرار دستی (`manual`) |
-| **C** | معوق، فقط بازدید برنامه‌ریزی‌شده یا هماهنگی در انتظار |
-| **D** | معوق، هم قرار دستی و هم بازدید برنامه‌ریزی‌شده |
+| منبع | تعریف | فیلتر |
+|---|---|---|
+| `manual` | ستون `visit_hold_until` (تعویق از فرم هماهنگی) | `?view=manual` |
+| `scheduled` | اقدام `bazdid` + `waite` با تاریخ آینده | `?view=scheduled` |
+| `coordination` | اقدام `hamahangi` (waite/finish) با تاریخ آینده | `?view=coordination` |
+
+> **باگ قبلی:** `coordination` با `scheduled` در یک گروه جمع می‌شد؛ نتیجه اینکه
+> مشتریانی که فقط «هماهنگی» داشتند در نمای «بازدید برنامه‌ریزی‌شده» دیده
+> می‌شدند و برچسب «بازدید برنامه‌ریزی‌شده» می‌گرفتند. حالا هر منبع فیلتر و
+> ستون خودش را دارد.
 
 ### فیلترها (قابل بوکمارک و ترکیب با جست‌وجو)
 
 | URL | نمایش | شامل |
 |---|---|---|
-| `/panel/entezar/` (بدون پارامتر) | **پیش‌فرض = فقط A** (رفتار قبلی صفحه) | A |
-| `?view=uncoordinated` | بدون قرار | A |
-| `?view=manual` | قرار هماهنگی | B + D |
-| `?view=scheduled` | بازدید برنامه‌ریزی‌شده | C + D |
-| `?view=coordinated` | همهٔ دارای قرار | B + C + D |
-| `?view=all` | همهٔ معوق‌ها | A + B + C + D |
-| مقدار نامعتبر | برگشت به پیش‌فرض، **بدون خطا** | A |
+| `/panel/entezar/` (بدون پارامتر) | **پیش‌فرض = بدون قرار** (رفتار قبلی) | بدون هیچ منبع |
+| `?view=uncoordinated` | بدون قرار | بدون هیچ منبع |
+| `?view=manual` | قرار دستی | هر مشتری با `manual` |
+| `?view=scheduled` | بازدید برنامه‌ریزی‌شده | هر مشتری با `scheduled` |
+| `?view=coordination` | هماهنگی | هر مشتری با `coordination` |
+| `?view=coordinated` | همهٔ دارای قرار | اجتماع هر سه منبع |
+| `?view=all` | همهٔ معوق‌ها | همه |
+| مقدار نامعتبر | برگشت به پیش‌فرض، **بدون خطا** | بدون هیچ منبع |
+
+چون یک مشتری می‌تواند چند منبع داشته باشد، در چند فیلتر دیده می‌شود؛ اما در
+`?view=coordinated` فقط **یک‌بار** شمرده می‌شود. به همین دلیل جمع سه کارت منبع
+می‌تواند از «با قرار» بیشتر باشد (صفحه این را در راهنمای بالای خود توضیح می‌دهد).
 
 ### ستون‌های جدول
 
 | ستون | توضیح |
 |---|---|
-| وضعیت قرار | برچسب «با قرار» / «بدون قرار» |
-| قرار هماهنگی | تاریخ شمسی قرار دستی (یا —) |
-| بازدید برنامه‌ریزی‌شده | تاریخ شمسی قرار `Action` (یا —) |
+| وضعیت قرار | «بدون قرار» / «قرار دستی» / «بازدید برنامه» / «هماهنگی» / «N قرار» |
+| قرار دستی | تاریخ شمسی قرار دستی (یا —) |
+| بازدید برنامه‌ریزی‌شده | تاریخ شمسی اقدام بازدید با تاریخ آینده (یا —) |
+| هماهنگی | تاریخ شمسی اقدام هماهنگی با تاریخ آینده (یا —) |
 | آخرین بازدید | بدون تغییر نسبت به قبل |
 
 ### شمارندهٔ داشبورد
 
-`CacheTable('9mahbazdid')` = **گروه A** (کارِ فوری = بدون قرار). هر بار باز شدن
-صفحه به‌روز می‌شود.
+`CacheTable('9mahbazdid')` = **بدون قرار** (کارِ فوری). هر بار باز شدن صفحه
+به‌روز می‌شود. با تغییر تفکیک، این عدد **تغییر نمی‌کند**.
 
 ---
 
@@ -461,8 +496,11 @@ python manage.py test tests
 ## ۹. آنچه تغییر نکرد
 
 - منطق «چه کسی عقب‌افتاده است» (همان `last_visit_map` + `due_cut`).
-- قاعدهٔ اعتبار قرار دستی (وجود هماهنگی فعال).
-- اسکنر پیامک، `recalc_last_bazdid` و چرخهٔ ۹ ماهه.
+- قاعدهٔ اعتبار قرار دستی (وجود هماهنگی فعال + آخرین فعالیت بودن).
+- `visit_policy.py` به‌طور کامل: `next_appointment_map`، `scheduled_visits_map`،
+  `coordination_holds_map` — پس **اسکنر پیامک**، `recalc_last_bazdid` و چرخهٔ
+  ۹ ماهه دقیقاً مثل قبل کار می‌کنند.
+- شمارندهٔ داشبورد (`CacheTable('9mahbazdid')` = بدون قرار).
 - لینک‌های قدیمی `?view=...` و رفتار پیش‌فرض (نمای «بدون قرار»).
 
 ## ۱۰. پارامترهای URL
@@ -470,9 +508,10 @@ python manage.py test tests
 ```
 /panel/entezar/                                  نمای پیش‌فرض (بدون قرار، قدیمی‌ترین)
 ?view=all                                        همهٔ معوق‌ها
-?view=coordinated                                با قرار
-?view=manual                                     فقط قرار هماهنگی
+?view=coordinated                                با قرار (اجتماع سه منبع)
+?view=manual                                     فقط قرار دستی
 ?view=scheduled                                  فقط بازدید برنامه‌ریزی‌شده
+?view=coordination                               فقط هماهنگی
 ?sort=overdue                                    بیشترین تأخیر اول
 ?sort=newest                                     جدیدترین بازدید اول
 ?searchVal=رضایی&searchOn=name                   جست‌وجوی نام