From 8385d11c112a2d1ba29a9e1a227669547745b211 Mon Sep 17 00:00:00 2001 From: Claude Date: Sat, 5 Sep 2026 23:31:07 +0000 Subject: [PATCH] docs(service): name the eighth case list view on the SLA page MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit `sla-and-escalation` told a service manager that `crm_case` ships **seven** views and then hand-copied the roster behind that count. The copy was one view short: **Unassigned — triage** was missing, in all three faces on the same line. Re-derived from the file the sentence already cites. Two independent readings of `src/views/case.view.ts` agree on eight list views: the default `list:` block (*All Cases*) plus seven `listViews` entries — *Service Workflow*, *SLA Calendar*, *Case Timeline*, *My Open Cases*, *Unassigned — triage*, *Escalated Cases*, *⏰ SLA at Risk*. The second reading is off the built artifact (`dist/objectstack.json`), not a grep, which is what settles the two shapes a pattern cannot: `list.calendar` is a config block on the default grid (`{startDateField, titleField, colorField}`), not a ninth view, and `web_to_case` sits under `formViews`, so it is outside a list-view count. The missing view is the one this page most needs named. **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, and its other claims were re-measured against the same file and hold: `is_sla_violated` appears in `case.view.ts` only as a column on *All Cases* and in a docblock — no view filters on it — so **Escalated Cases** is still the closest workable list. Prose only. No `src/` change, no view added, renamed or removed. The eighth name is spelled in English on both Chinese faces, matching the seven siblings in that same sentence and the whole page, which names every view in English. That page-wide convention is not this change's to settle and is reported separately: the `zh-CN` pack carries a Chinese label for all eight. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_018xtjdpZFjgWh4Ad9Wcx68J --- .../sla-page-names-the-eighth-case-view.md | 33 +++++++++++++++++++ content/docs/service/sla-and-escalation.mdx | 2 +- .../service/sla-and-escalation.zh-Hans.mdx | 2 +- .../service/sla-and-escalation.zh-Hant.mdx | 2 +- 4 files changed, 36 insertions(+), 3 deletions(-) create mode 100644 .changeset/sla-page-names-the-eighth-case-view.md diff --git a/.changeset/sla-page-names-the-eighth-case-view.md b/.changeset/sla-page-names-the-eighth-case-view.md new file mode 100644 index 00000000..88a30f81 --- /dev/null +++ b/.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. diff --git a/content/docs/service/sla-and-escalation.mdx b/content/docs/service/sla-and-escalation.mdx index f6def612..01142be9 100644 --- a/content/docs/service/sla-and-escalation.mdx +++ b/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. diff --git a/content/docs/service/sla-and-escalation.zh-Hans.mdx b/content/docs/service/sla-and-escalation.zh-Hans.mdx index d5252975..cd7aee30 100644 --- a/content/docs/service/sla-and-escalation.zh-Hans.mdx +++ b/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**。 diff --git a/content/docs/service/sla-and-escalation.zh-Hant.mdx b/content/docs/service/sla-and-escalation.zh-Hant.mdx index cce5ba37..edec6db1 100644 --- a/content/docs/service/sla-and-escalation.zh-Hant.mdx +++ b/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**。