fix(service): the SLA Violations tile counts open breaches at read time

.changeset/2070-sla-tile-read-time.md

@@ -0,0 +1,5 @@
+---
+'hotcrm': patch
+---
+
+The **SLA Violations** tile on the service dashboard now counts open breaches when it is read, so it is right on every deployment, including one that runs no scheduled work (the platform default). It used to count only cases flagged **SLA Violated**, and an open case is flagged only by the hourly SLA sweep, which never runs where scheduled work is off. Such a deployment showed far fewer violations than it had: on a fresh demo database the tile read **13** while **29** cases had breached. The tile now counts a case that is flagged, or a case that is still open (neither *Resolved* nor *Closed*) and whose **SLA Due Date** has passed, using the same rule the sweep applies. A fresh demo database now shows **29**. The tile only counts: escalating a breached case and alerting its owner still need the sweep, so where it does not run, an open breach is in the count but not yet in **Escalated Cases**.

content/docs/service/cases.mdx

@@ -184,7 +184,7 @@ Nothing else claims a case, and each exclusion is deliberate:
 
 Of the **seven** names this section used to list, only **My Open Cases** was real — it survives in the table above. The other six are not views at all:
 
-- **Critical Cases** is a metric tile, not a list. *Breached SLA* is not a name this app carries at all: the tile that counts breaches is **SLA Violations**. [Service Overview](/docs/analytics/dashboards) — the dashboard's own title is **Customer Service** — carries **Critical Cases** (open and Critical) and **SLA Violations** (`is_sla_violated` is true); no list view in this app filters on a breach. For a list you can actually work through, use **Escalated Cases** — the SLA sweep escalates every case it flags, so each breach lands there.
+- **Critical Cases** is a metric tile, not a list. *Breached SLA* is not a name this app carries at all: the tile that counts breaches is **SLA Violations**. [Service Overview](/docs/analytics/dashboards) — the dashboard's own title is **Customer Service** — carries **Critical Cases** (open and Critical) and **SLA Violations** (flagged **SLA Violated**, or still open past its **SLA Due Date**, counted when the tile is read); no list view in this app filters on a breach. For a list you can actually work through, use **Escalated Cases** — the SLA sweep escalates every case it flags, so each breach it flags lands there.
 - **Service Board** is not this app's name for anything. The kanban is **Service Workflow**, and that is what its tab reads.
 - **Cases Due Today**, **Recently Closed** and **By Account** do not exist in any form: no view filters on today's due date or on `closed_date`, and `crm_case` has no grouped view.
 

content/docs/service/cases.zh-Hans.mdx

@@ -184,7 +184,7 @@ description: 客户支持工单——主题、优先级、状态、解决方案
 
 本节原先列的七个名字里，有六个根本不是视图：
 
-- **Critical Cases** 是指标磁贴，不是列表。*Breached SLA* 这个名字本应用根本没有：按违约计数的是 **SLA Violations** 磁贴。[服务概览](/zh-Hans/docs/analytics/dashboards)（Service Overview；该仪表盘自身的标题是 **Customer Service**）上有 **Critical Cases**（未结且 Critical）和 **SLA Violations**（`is_sla_violated` 为真）两个磁贴；本应用里没有任何一个列表视图按违约过滤。真要有一份能逐条处理的清单，用 **已升级工单**——SLA 扫描会把它标记的每一条都升级，所以每次违约都会落到那里。
+- **Critical Cases** 是指标磁贴，不是列表。*Breached SLA* 这个名字本应用根本没有：按违约计数的是 **SLA Violations** 磁贴。[服务概览](/zh-Hans/docs/analytics/dashboards)（Service Overview；该仪表盘自身的标题是 **Customer Service**）上有 **Critical Cases**（未结且 Critical）和 **SLA Violations**（已标记 **SLA Violated**，或仍未结且 **SLA 截止日期**已过，读取磁贴时计数）两个磁贴；本应用里没有任何一个列表视图按违约过滤。真要有一份能逐条处理的清单，用 **已升级工单**——SLA 扫描会把它标记的每一条都升级，所以它标记的每次违约都会落到那里。
 - **Service Board** 不是本应用里任何东西的名字。看板叫 **服务流转**，页签上写的也是这个名字。
 - **Cases Due Today**、**Recently Closed** 与 **By Account** 以任何形式都不存在：没有任何视图按「截止日期 = 今天」或 `closed_date` 过滤，`crm_case` 上也没有任何分组视图。
 

content/docs/service/cases.zh-Hant.mdx

@@ -186,7 +186,7 @@ description: 客戶支援工單——主題、優先順序、狀態、解決方
 
 本節原先列的七個名字裡，有六個根本不是檢視：
 
-- **Critical Cases** 是指標磁貼，不是列表。*Breached SLA* 這個名字本應用根本沒有：按違約計數的是 **SLA Violations** 磁貼。[服務概覽](/zh-Hant/docs/analytics/dashboards)（Service Overview；該儀表板自身的標題是 **Customer Service**）上有 **Critical Cases**（未結且 Critical）和 **SLA Violations**（`is_sla_violated` 為真）兩個磁貼；本應用裡沒有任何一個列表檢視按違約過濾。真要有一份能逐條處理的清單，用 **已升級工單**——SLA 掃描會把它標記的每一條都升級，所以每次違約都會落到那裡。
+- **Critical Cases** 是指標磁貼，不是列表。*Breached SLA* 這個名字本應用根本沒有：按違約計數的是 **SLA Violations** 磁貼。[服務概覽](/zh-Hant/docs/analytics/dashboards)（Service Overview；該儀表板自身的標題是 **Customer Service**）上有 **Critical Cases**（未結且 Critical）和 **SLA Violations**（已標記 **SLA Violated**，或仍未結且 **SLA 截止日期**已過，讀取磁貼時計數）兩個磁貼；本應用裡沒有任何一個列表檢視按違約過濾。真要有一份能逐條處理的清單，用 **已升級工單**——SLA 掃描會把它標記的每一條都升級，所以它標記的每次違約都會落到那裡。
 - **Service Board** 不是本應用裡任何東西的名字。看板叫 **服務流轉**，頁籤上寫的也是這個名字。
 - **Cases Due Today**、**Recently Closed** 與 **By Account** 以任何形式都不存在：沒有任何檢視按「截止日期 = 今天」或 `closed_date` 過濾，`crm_case` 上也沒有任何分組檢視。
 

content/docs/service/sla-and-escalation.mdx

@@ -143,7 +143,7 @@ If priority resolves to **Critical**, the Copilot immediately recommends escalat
 | **Service Director** | SLA Performance report | Weekly |
 | **Executive** | Service Overview | Weekly |
 
-Two names this table used to carry are not views at all. **Breached SLA** and **Critical Cases** do not exist as list views: `crm_case` ships eight — *All Cases*, *Service Workflow*, *SLA Calendar*, *Case Timeline*, *My Open Cases*, *Unassigned — triage*, *Escalated Cases* and *⏰ SLA at Risk* (`src/service/views/case.view.ts`) — and not one of them filters on **SLA Violated**. The only two surfaces that do filter on a breach are metric tiles on [Service Overview](/docs/analytics/dashboards): **SLA Violations** (`is_sla_violated: true`) and **Critical Cases** (open and Critical). For a list you can actually work through, **Escalated Cases** is the closest thing: `case_sla_monitor` escalates every case it flags as breached, so each breach found on an open case lands in it — mixed in with the cases escalated on priority alone. (A case flagged on the save that resolved or closed it late is finished work: the **SLA Violations** tile counts it, and there is nothing left in it to work.)
+Two names this table used to carry are not views at all. **Breached SLA** and **Critical Cases** do not exist as list views: `crm_case` ships eight — *All Cases*, *Service Workflow*, *SLA Calendar*, *Case Timeline*, *My Open Cases*, *Unassigned — triage*, *Escalated Cases* and *⏰ SLA at Risk* (`src/service/views/case.view.ts`) — and not one of them filters on **SLA Violated**. The only two surfaces that do filter on a breach are metric tiles on [Service Overview](/docs/analytics/dashboards): **SLA Violations** (flagged **SLA Violated**, or still open with its **SLA Due Date** passed — counted when the tile is read, so it is right with or without the sweep, which is still what escalates them) and **Critical Cases** (open and Critical). For a list you can actually work through, **Escalated Cases** is the closest thing: `case_sla_monitor` escalates every case it flags as breached, so each breach found on an open case lands in it — mixed in with the cases escalated on priority alone. (A case flagged on the save that resolved or closed it late is finished work: the **SLA Violations** tile counts it, and there is nothing left in it to work.)
 
 **My Open Cases is sorted by priority, not by SLA Due Date.** Its keys are `priority_rank` descending first, and `sla_due_date` ascending only as a tie-breaker (`src/service/views/case.view.ts`) — so a Low case due within the hour still sits below every Critical one. The tie-breaker does now have values to work with at every priority, so within a band the soonest deadline comes first. Keep **SLA at Risk** or **SLA Calendar** open next to it if you are working to deadlines.
 

content/docs/service/sla-and-escalation.zh-Hans.mdx

@@ -143,7 +143,7 @@ SLA（服务级别协议）系统为**每一张工单**打上一个**截止时
 | **服务总监** | SLA 表现报表 | 每周 |
 | **高管** | 服务概览 | 每周 |
 
-这张表过去写的两个名字根本不是视图。**Breached SLA** 与 **Critical Cases** 都不存在于列表视图里：`crm_case` 随产品提供的视图一共八个——*全部工单*、*服务流转*、*SLA 日历*、*工单时间线*、*我的待处理工单*、*未分派 — 待分诊*、*已升级工单* 与 *⏰ SLA 风险预警*（`src/service/views/case.view.ts`）——其中没有任何一个以 **SLA 已违约**为过滤条件。真正按违约过滤的只有[服务概览](/zh-Hans/docs/analytics/dashboards)上的两个指标磁贴：**SLA Violations**（`is_sla_violated: true`）与 **Critical Cases**（未结 + Critical）。如果你要的是一份能逐条处理的列表，**已升级工单** 是最接近的那个：`case_sla_monitor` 会把它标记为违约的每一个工单都升级掉，所以工单仍然打开时发现的每一次违约都会落进这个视图——只是会和那些仅因优先级而升级的工单混在一起。（在解决或关闭的那次保存里因超时而被标记的工单已经结束：**SLA Violations** 磁贴会把它计入，但它已经没有什么可再处理的了。）
+这张表过去写的两个名字根本不是视图。**Breached SLA** 与 **Critical Cases** 都不存在于列表视图里：`crm_case` 随产品提供的视图一共八个——*全部工单*、*服务流转*、*SLA 日历*、*工单时间线*、*我的待处理工单*、*未分派 — 待分诊*、*已升级工单* 与 *⏰ SLA 风险预警*（`src/service/views/case.view.ts`）——其中没有任何一个以 **SLA 已违约**为过滤条件。真正按违约过滤的只有[服务概览](/zh-Hans/docs/analytics/dashboards)上的两个指标磁贴：**SLA Violations**（已标记 **SLA 已违约**，或仍未结且 **SLA 截止日期**已过——读取磁贴时才计数，所以有没有扫描它都是准的；升级这些工单的仍然是扫描）与 **Critical Cases**（未结 + Critical）。如果你要的是一份能逐条处理的列表，**已升级工单** 是最接近的那个：`case_sla_monitor` 会把它标记为违约的每一个工单都升级掉，所以工单仍然打开时发现的每一次违约都会落进这个视图——只是会和那些仅因优先级而升级的工单混在一起。（在解决或关闭的那次保存里因超时而被标记的工单已经结束：**SLA Violations** 磁贴会把它计入，但它已经没有什么可再处理的了。）
 
 **我的待处理工单是按优先级排序的，不是按 SLA 截止日期。** 它的排序键是 `priority_rank` 降序在先、`sla_due_date` 升序仅作次级键（`src/service/views/case.view.ts`）——所以一个一小时后就到期的 Low 工单，仍然排在每一个 Critical 工单下面。不过次级键现在在每一档里都有值可排了，同一档内最早到期的排在最前面。如果你是按截止时间在干活，请在它旁边同时开着 **SLA 风险预警** 或 **SLA 日历**。
 

content/docs/service/sla-and-escalation.zh-Hant.mdx

@@ -145,7 +145,7 @@ SLA（服務級別協議）系統為**每一張工單**打上一個**截止時
 | **服務總監** | SLA 表現報表 | 每週 |
 | **高管** | 服務概覽 | 每週 |
 
-這張表過去寫的兩個名字根本不是檢視。**Breached SLA** 與 **Critical Cases** 都不存在於列表檢視裡：`crm_case` 隨產品提供的檢視一共八個——*All Cases*、*Service Workflow*、*SLA Calendar*、*Case Timeline*、*My Open Cases*、*Unassigned — triage*、*Escalated Cases* 與 *⏰ SLA at Risk*（`src/service/views/case.view.ts`）——其中沒有任何一個以 **SLA 已違約**為過濾條件。真正按違約過濾的只有[服務概覽](/zh-Hant/docs/analytics/dashboards)上的兩個指標磁貼：**SLA Violations**（`is_sla_violated: true`）與 **Critical Cases**（未結 + Critical）。如果你要的是一份能逐條處理的列表，**Escalated Cases** 是最接近的那個：`case_sla_monitor` 會把它標記為違約的每一個工單都升級掉，所以工單仍然打開時發現的每一次違約都會落進這個檢視——只是會和那些僅因優先順序而升級的工單混在一起。（在解決或關閉的那次儲存裡因超時而被標記的工單已經結束：**SLA Violations** 磁貼會把它計入，但它已經沒有什麼可再處理的了。）
+這張表過去寫的兩個名字根本不是檢視。**Breached SLA** 與 **Critical Cases** 都不存在於列表檢視裡：`crm_case` 隨產品提供的檢視一共八個——*All Cases*、*Service Workflow*、*SLA Calendar*、*Case Timeline*、*My Open Cases*、*Unassigned — triage*、*Escalated Cases* 與 *⏰ SLA at Risk*（`src/service/views/case.view.ts`）——其中沒有任何一個以 **SLA 已違約**為過濾條件。真正按違約過濾的只有[服務概覽](/zh-Hant/docs/analytics/dashboards)上的兩個指標磁貼：**SLA Violations**（已標記 **SLA 已違約**，或仍未結且 **SLA 截止日期**已過——讀取磁貼時才計數，所以有沒有掃描它都是準的；升級這些工單的仍然是掃描）與 **Critical Cases**（未結 + Critical）。如果你要的是一份能逐條處理的列表，**Escalated Cases** 是最接近的那個：`case_sla_monitor` 會把它標記為違約的每一個工單都升級掉，所以工單仍然打開時發現的每一次違約都會落進這個檢視——只是會和那些僅因優先順序而升級的工單混在一起。（在解決或關閉的那次儲存裡因超時而被標記的工單已經結束：**SLA Violations** 磁貼會把它計入，但它已經沒有什麼可再處理的了。）
 
 **My Open Cases 是按優先順序排序的，不是按 SLA 截止日期。** 它的排序鍵是 `priority_rank` 降序在先、`sla_due_date` 升序僅作次級鍵（`src/service/views/case.view.ts`）——所以一個一小時後就到期的 Low 工單，仍然排在每一個 Critical 工單下面。不過次級鍵現在在每一檔裡都有值可排了，同一檔內最早到期的排在最前面。如果你是按截止時間在幹活，請在它旁邊同時開著 **SLA at Risk** 或 **SLA Calendar**。