docs(service): name the eighth case list view on the SLA page

.changeset/sla-page-names-the-eighth-case-view.md

@@ -0,0 +1,33 @@
+---
+'hotcrm': patch
+---
+
+Name all eight case list views on the SLA & Escalation page. The page told a
+service manager that `crm_case` ships **seven** views and then hand-copied the
+roster behind that count, and the copy was one view short: **Unassigned —
+triage** was missing from the list, in all three faces (`en`, `zh-Hans`,
+`zh-Hant`) on the same line.
+
+The count and the roster are one sentence doing two jobs, and both went stale
+together when the eighth view landed. Re-derived from the file the sentence
+already cites, `src/views/case.view.ts`: the object declares a default `list:`
+view (*All Cases*) plus seven `listViews` entries — *Service Workflow*, *SLA
+Calendar*, *Case Timeline*, *My Open Cases*, *Unassigned — triage*, *Escalated
+Cases*, *⏰ SLA at Risk* — which is eight. Two neighbours that look like views
+in a grep are not: the `calendar:` block inside `list:` is that grid's calendar
+visualization binding, and `web_to_case` is a `formViews` entry, not a list
+view. The sibling Cases page already documented eight; this page is what
+disagreed.
+
+The missing view is the one a manager most needs named here: **Unassigned —
+triage** is where a web-to-case submission lands when nobody holds the Service
+Agent position, so a page about SLA deadlines that omits it hides the queue
+where unowned cases run their clock down.
+
+Nothing else in the paragraph moved. Its other claims were re-measured against
+the same file and hold: no case list view filters on **SLA Violated**
+(`is_sla_violated` appears in `case.view.ts` only as a column on *All Cases*),
+so **Escalated Cases** is still the closest workable list, and the two surfaces
+that do filter on a breach are still dashboard tiles rather than views.
+
+Prose only — no metadata changed, and no view was added, renamed or removed.

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

@@ -141,7 +141,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 seven — *All Cases*, *Service Workflow*, *SLA Calendar*, *Case Timeline*, *My Open Cases*, *Escalated Cases* and *⏰ SLA at Risk* (`src/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 lands in it — mixed in with the cases escalated on priority alone.
+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/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 lands in it — mixed in with the cases escalated on priority alone.
 
 **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/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

@@ -141,7 +141,7 @@ SLA（服务级别协议）系统为**每一张工单**打上一个**截止时
 | **服务总监** | SLA 表现报表 | 每周 |
 | **高管** | 服务概览 | 每周 |
 
-这张表过去写的两个名字根本不是视图。**Breached SLA** 与 **Critical Cases** 都不存在于列表视图里：`crm_case` 随产品提供的视图一共七个——*All Cases*、*Service Workflow*、*SLA Calendar*、*Case Timeline*、*My Open Cases*、*Escalated Cases* 与 *⏰ SLA at Risk*（`src/views/case.view.ts`）——其中没有任何一个以 **SLA 已违约**为过滤条件。真正按违约过滤的只有[服务概览](/zh-Hans/docs/analytics/dashboards)上的两个指标磁贴：**SLA Violations**（`is_sla_violated: true`）与 **Critical Cases**（未结 + Critical）。如果你要的是一份能逐条处理的列表，**Escalated Cases** 是最接近的那个：`case_sla_monitor` 会把它标记为违约的每一个工单都升级掉，所以每一次违约都会落进这个视图——只是会和那些仅因优先级而升级的工单混在一起。
+这张表过去写的两个名字根本不是视图。**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/views/case.view.ts`）——其中没有任何一个以 **SLA 已违约**为过滤条件。真正按违约过滤的只有[服务概览](/zh-Hans/docs/analytics/dashboards)上的两个指标磁贴：**SLA Violations**（`is_sla_violated: true`）与 **Critical Cases**（未结 + Critical）。如果你要的是一份能逐条处理的列表，**Escalated Cases** 是最接近的那个：`case_sla_monitor` 会把它标记为违约的每一个工单都升级掉，所以每一次违约都会落进这个视图——只是会和那些仅因优先级而升级的工单混在一起。
 
 **My Open Cases 是按优先级排序的，不是按 SLA 截止日期。** 它的排序键是 `priority_rank` 降序在先、`sla_due_date` 升序仅作次级键（`src/views/case.view.ts`）——所以一个一小时后就到期的 Low 工单，仍然排在每一个 Critical 工单下面。不过次级键现在在每一档里都有值可排了，同一档内最早到期的排在最前面。如果你是按截止时间在干活，请在它旁边同时开着 **SLA at Risk** 或 **SLA Calendar**。
 

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

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