docs(service): document the triage claim gesture in all three locales

.changeset/document-the-triage-claim-gesture.md

@@ -0,0 +1,33 @@
+---
+'hotcrm': patch
+---
+
+Document the triage claim gesture, in all three locales.
+
+The claim seam shipped without its documentation half: an unowned case in
+**Unassigned — triage** becomes yours when you move it to *In Progress*,
+*Waiting on Customer* or *Waiting on Support* — the app stamps you as its Owner
+in the same save — after which it leaves that tab and appears in **My Open
+Cases**. That was real behaviour with nothing written down, because the PR that
+landed it could not touch `content/docs/**`.
+
+`service/cases` now carries the gesture end to end: the three statuses that
+claim, the four that deliberately do not (*New* is the state the row is already
+in; *Escalated* belongs to the escalation hand-off; resolving or closing a case
+is not picking it up, and leaves it ownerless), and the reason the claim cannot
+be spelled as an owner edit — a save carrying Owner is refused for an agent
+whatever name it holds, so the status move is the only spelling and the only
+name it can write is the caller's own.
+
+`administration/sharing-and-security` gains the admin-facing half:
+*Unassigned Cases — Triage* is the one shipped rule meant to be **spent** rather
+than held — it opens an unowned case to every `service_agent`, and the claim is
+what ends the grant. Claiming is added to the list of everyday actions that
+write Owner without being transfers, which is why the gesture needs no new
+permission.
+
+Two accuracy fixes ride along on the pages being edited. The rule's row said
+`service_agent` gets unowned **cases that are not closed**; the rule also
+excludes *Resolved*, so the row overstated the grant in all three locales. And
+the two Chinese pages' rows are confirmed present — the earlier gap they were
+filed for is already closed.

content/docs/administration/sharing-and-security.mdx

@@ -94,7 +94,7 @@ Criteria-based rules are the enforced flavour: matching records materialise real
 | Large Open Deals — Executive | Opportunity | Read | `executive` — the same deals, one rung up |
 | Escalated Cases Sharing | Case | Edit | `service_manager` — open critical cases |
 | Escalated Cases — Service Director | Case | Read | `service_director` — the same cases, one rung up |
-| Unassigned Cases — Triage | Case | Edit | `service_agent` — open cases with no owner |
+| Unassigned Cases — Triage | Case | Edit | `service_agent` — unowned cases, until they are Resolved or Closed |
 | Live Campaigns — Marketing Manager | Campaign | Edit | `marketing_manager` — planning / in-progress campaigns |
 | Live Campaigns — Marketing Director | Campaign | Edit | `marketing_director` — the same campaigns |
 
@@ -111,6 +111,28 @@ Create your own in **Setup → Sharing Rules**.
 > UI marks such a rule as broken, so when a team reports missing records, check
 > that every field the rule names is a plain field on the object.
 
+### A grant meant to be spent: *Unassigned Cases — Triage*
+
+Most sharing rules are standing openings: a rule that matches a record today matches it again tomorrow, and the recipients keep the access for as long as the record fits the criteria. *Unassigned Cases — Triage* is the one rule built to be **used up**. It grants every `service_agent` **Edit** on cases that have no owner and are neither *Resolved* nor *Closed* — the grant behind the case list's **Unassigned — triage** tab — and it exists so that an agent can take one of those cases. Taking it is what ends the grant:
+
+1. A case arrives with **no owner** — a web-to-case submission that landed while nobody held the Service Agent position. The rule matches it, so every service agent can see and edit it.
+2. An agent moves it to **In Progress**, **Waiting on Customer** or **Waiting on Support**. The app stamps that agent as the case's **Owner** in the same save.
+3. The case now has an owner, so the rule no longer matches. It drops out of the shared pool and out of the tab, and the agent holds it the ordinary way — as its owner.
+
+> **The claim writes Owner without anyone holding a transfer permission, and
+> that is the design rather than a gap.** Service Agent may reassign tasks only
+> (see *Ownership and transfers* below), and a save that carries Owner is
+> refused for an agent whatever name it holds — their own included. So the claim
+> is not an owner edit that got approved: it is a **status move the app reads as
+> "I am taking this"**, and the only name it can write is the caller's own, onto
+> a case that has no owner yet. *Claim it for somebody else* and *claim a case
+> somebody already owns* have no spelling at all, which is why the gesture needs
+> no new permission. It is not agent-only either: anyone who moves an unowned
+> open case into one of those three statuses claims it that way, an
+> administrator or a service manager included. Automation does not — a seeded or
+> system write leaves the case ownerless, which is what keeps first-install
+> intake visible in the tab.
+
 ### A rule widens one object, not the records underneath it
 
 Sharing rules are authored **per object**. Widening `Account` widens accounts — the records hanging off a shared account keep their own baseline, and Contact is the only one derived from it:
@@ -166,14 +188,19 @@ from ordinary edit rights:
 | Service Agent | tasks only (so an escalation can hand work to the account owner) |
 | Sales Rep, Marketing User | nothing — records are assigned *to* them |
 
-Three everyday actions are **not** transfers and need no such permission:
+Four everyday actions are **not** transfers and need no such permission:
 
 - **Creating a record.** New records are stamped to their creator automatically —
   you never pick yourself.
 - **Saving a form** without touching Owner, even though the form submits the
   field.
 - **Automation acting on your behalf** — the round-robin that routes an incoming
   lead, the nightly sweeps that book renewal and follow-up tasks.
+- **Claiming an unowned case.** Moving a case that has nobody on it into *In
+  Progress*, *Waiting on Customer* or *Waiting on Support* makes you its owner
+  (see *A grant meant to be spent* above). Owner does change — but the move
+  names no one, takes the record away from no one, and works only while the case
+  is ownerless, so it is not a reassignment and needs no reassignment right.
 
 A user without the permission who tries to reassign gets a clear refusal rather
 than a silent no-op. If you need to move a book of business, ask an

content/docs/administration/sharing-and-security.zh-Hans.mdx

@@ -94,14 +94,24 @@ na_sales_team       eu_sales_team          （区域分组）
 | Large Open Deals — Executive | 商机 | 读取 | `executive` —— 同一批交易，上一层级 |
 | Escalated Cases Sharing | 工单 | 编辑 | `service_manager` —— 未关闭的紧急工单 |
 | Escalated Cases — Service Director | 工单 | 读取 | `service_director` —— 同一批工单，上一层级 |
-| Unassigned Cases — Triage | 工单 | 编辑 | `service_agent` —— 没有负责人的未关闭工单 |
+| Unassigned Cases — Triage | 工单 | 编辑 | `service_agent` —— 没有负责人的工单，直到它被 Resolved 或 Closed |
 | Live Campaigns — Marketing Manager | 营销活动 | 编辑 | `marketing_manager` —— 筹划中 / 进行中的活动 |
 | Live Campaigns — Marketing Director | 营销活动 | 编辑 | `marketing_director` —— 同一批活动 |
 
 在 **设置 → 共享规则** 中创建你自己的规则。
 
 > **条件只能过滤普通字段，不能过滤地址的某一部分。** 两条区域规则匹配的是客户上的 **账单国家** —— 一个只读的两位国家代码，由你在 **账单地址** 中填写的国家推导而来 —— 而不是地址本身。条件规则必须以数据库查询的形式运行，而查询无法深入结构化的地址或位置值内部。因此，针对 `账单地址 → 国家` 编写的规则会被**直接拒绝**，而不是被悄悄放宽成"所有客户"：它根本不会被安装，它指定的岗位也就什么都拿不到。界面上不会把这样的规则标记为失效，所以当某个团队反馈记录缺失时，请检查规则里引用的每个字段是否都是该对象上的普通字段。
 
+### 一条为「被用掉」而设的授权：*Unassigned Cases — Triage*
+
+大多数共享规则是常设的开口：今天匹配某条记录的规则明天照样匹配它，只要记录还符合条件，接收方就一直持有那份访问权。*Unassigned Cases — Triage* 是唯一一条**为被用掉而设计**的规则。它把**编辑**权授予每一位 `service_agent`，覆盖没有负责人、且既不是 *Resolved* 也不是 *Closed* 的工单——也就是工单列表里 **Unassigned — triage** 标签页背后的那条授权——它存在的意义，就是让某位客服把其中一张工单接走。而接走它，正是这份授权终结的方式：
+
+1. 一张工单**没有负责人**地到达——比如没有人担任服务坐席时 Web 提交进来的那种。规则匹配上了它，于是每一位客服都能看到并编辑它。
+2. 某位客服把它转到 **In Progress**、**Waiting on Customer** 或 **Waiting on Support**。应用在同一次保存里把这位客服标记为该工单的**负责人**。
+3. 工单现在有负责人了，规则不再匹配它。它退出共享池、也退出那个标签页，而这位客服从此以负责人的身份、用最普通的方式持有它。
+
+> **认领会写入负责人，却不需要任何人持有转移权限——这是设计，不是漏洞。** 客服专员只能转移任务（见下文*归属与转移*），而带着负责人字段的保存对客服一律被拒绝，无论填的是谁，填他自己也一样。所以认领不是一次「被批准的负责人编辑」，而是一个**被应用读作「我把这张接了」的状态变更**：它能写入的名字只有调用者自己，而且只能写到一张还没有负责人的工单上。「替别人认领」和「认领一张已经有主的工单」根本没有写法，这正是这个动作不需要任何新权限的原因。它也不是客服专属的：任何人把一张无主的未结工单转入那三种状态，都以同样的方式认领了它，管理员和服务经理也不例外。自动化则不会——种子写入或系统写入让工单保持无主，这正是首次安装时那些工单还能留在标签页里被看见的原因。
+
 ### 一条规则放开的是一个对象，而不是它下面的记录
 
 共享规则是 **按对象** 编写的。放开 `Account` 只放开客户本身 —— 挂在这个客户下的记录仍然各自守着自己的基线，其中只有联系人是从客户派生的：
@@ -152,11 +162,12 @@ HotCRM **不提供客户团队对象** —— 客户上没有团队名单，也
 | 客服专员 | 仅任务（以便升级时把工作交给客户负责人） |
 | 销售代表、市场用户 | 无——记录是被指派给他们的 |
 
-有三类日常操作**不算**转移，因而不需要该权限：
+有四类日常操作**不算**转移，因而不需要该权限：
 
 - **新建记录。** 新记录会自动归属到创建者，你无需手动选择自己。
 - **保存表单**时未改动负责人——即使表单会把该字段一并提交。
 - **自动化代你执行**——分配新线索的轮询、夜间生成续约与跟进任务的批处理。
+- **认领一张无主工单。** 把一张没有任何人负责的工单转入 *In Progress*、*Waiting on Customer* 或 *Waiting on Support*，你就成了它的负责人（见上文*一条为「被用掉」而设的授权*）。负责人确实变了——但这个动作没有指定任何人、没有把记录从任何人手里拿走，而且只在工单无主时才起作用，所以它不是一次转移，也不需要转移权限。
 
 没有该权限的用户尝试转移时会收到明确的拒绝提示，而不是悄无声息地无效。需要整体移交业务簿时，请联系管理员或你的销售经理。
 

content/docs/administration/sharing-and-security.zh-Hant.mdx

@@ -94,14 +94,24 @@ na_sales_team       eu_sales_team          （區域分組）
 | Large Open Deals — Executive | 商機 | 讀取 | `executive` —— 同一批交易，上一層級 |
 | Escalated Cases Sharing | 案件 | 編輯 | `service_manager` —— 未關閉的緊急案件 |
 | Escalated Cases — Service Director | 案件 | 讀取 | `service_director` —— 同一批案件，上一層級 |
-| Unassigned Cases — Triage | 案件 | 編輯 | `service_agent` —— 沒有負責人的未關閉案件 |
+| Unassigned Cases — Triage | 案件 | 編輯 | `service_agent` —— 沒有負責人的案件，直到它被 Resolved 或 Closed |
 | Live Campaigns — Marketing Manager | 行銷活動 | 編輯 | `marketing_manager` —— 籌劃中 / 進行中的活動 |
 | Live Campaigns — Marketing Director | 行銷活動 | 編輯 | `marketing_director` —— 同一批活動 |
 
 在 **Setup → Sharing Rules** 中建立你自己的規則。
 
 > **條件只能過濾普通欄位，不能過濾地址的某一部分。** 兩條區域規則比對的是客戶上的 **帳單國家** —— 一個唯讀的兩位國家代碼，由你在 **帳單地址** 中填寫的國家推導而來 —— 而不是地址本身。條件規則必須以資料庫查詢的形式執行，而查詢無法深入結構化的地址或位置值內部。因此，針對 `帳單地址 → 國家` 撰寫的規則會被**直接拒絕**，而不是被悄悄放寬成「所有客戶」：它根本不會被安裝，它指定的職位也就什麼都拿不到。介面上不會把這樣的規則標記為失效，所以當某個團隊回報記錄缺失時，請檢查規則裡引用的每個欄位是否都是該物件上的普通欄位。
 
+### 一條為「被用掉」而設的授權：*Unassigned Cases — Triage*
+
+大多數共用規則是常設的開口：今天符合某筆記錄的規則明天照樣符合它，只要記錄還符合條件，接收方就一直持有那份存取權。*Unassigned Cases — Triage* 是唯一一條**為被用掉而設計**的規則。它把**編輯**權授予每一位 `service_agent`，涵蓋沒有負責人、且既不是 *Resolved* 也不是 *Closed* 的案件——也就是案件清單裡 **Unassigned — triage** 標籤頁背後的那條授權——它存在的意義，就是讓某位客服把其中一張案件接走。而接走它，正是這份授權終結的方式：
+
+1. 一張案件**沒有負責人**地抵達——比如沒有人擔任服務座席時 Web 提交進來的那種。規則符合了它，於是每一位客服都能看到並編輯它。
+2. 某位客服把它轉到 **In Progress**、**Waiting on Customer** 或 **Waiting on Support**。應用在同一次儲存裡把這位客服標記為該案件的**負責人**。
+3. 案件現在有負責人了，規則不再符合它。它退出共用池、也退出那個標籤頁，而這位客服從此以負責人的身分、用最普通的方式持有它。
+
+> **認領會寫入負責人，卻不需要任何人持有轉移權限——這是設計，不是漏洞。** 客服專員只能轉移任務（見下文*歸屬與轉移*），而帶著負責人欄位的儲存對客服一律被拒絕，無論填的是誰，填他自己也一樣。所以認領不是一次「被批准的負責人編輯」，而是一個**被應用讀作「我把這張接了」的狀態變更**：它能寫入的名字只有呼叫者自己，而且只能寫到一張還沒有負責人的案件上。「替別人認領」和「認領一張已經有主的案件」根本沒有寫法，這正是這個動作不需要任何新權限的原因。它也不是客服專屬的：任何人把一張無主的未結案件轉入那三種狀態，都以同樣的方式認領了它，管理員和服務經理也不例外。自動化則不會——種子寫入或系統寫入讓案件保持無主，這正是首次安裝時那些案件還能留在標籤頁裡被看見的原因。
+
 ### 一條規則放開的是一個物件，而不是它底下的記錄
 
 共用規則是 **按物件** 撰寫的。放開 `Account` 只放開客戶本身 —— 掛在這個客戶底下的記錄仍各自守著自己的基線，其中只有聯絡人是從客戶衍生的：
@@ -152,11 +162,12 @@ HotCRM **不提供客戶團隊物件** —— 客戶上沒有團隊名單，也
 | 客服專員 | 僅任務（以便升級時把工作交給客戶負責人） |
 | 銷售代表、行銷使用者 | 無——記錄是被指派給他們的 |
 
-有三類日常操作**不算**轉移，因此不需要該權限：
+有四類日常操作**不算**轉移，因此不需要該權限：
 
 - **建立記錄。** 新記錄會自動歸屬到建立者，你無需手動選擇自己。
 - **儲存表單**時未變更負責人——即使表單會把該欄位一併送出。
 - **自動化代你執行**——指派新潛在客戶的輪詢、夜間產生續約與跟進任務的批次作業。
+- **認領一張無主案件。** 把一張沒有任何人負責的案件轉入 *In Progress*、*Waiting on Customer* 或 *Waiting on Support*，你就成了它的負責人（見上文*一條為「被用掉」而設的授權*）。負責人確實變了——但這個動作沒有指定任何人、沒有把記錄從任何人手裡拿走，而且只在案件無主時才起作用，所以它不是一次轉移，也不需要轉移權限。
 
 沒有該權限的使用者嘗試轉移時會收到明確的拒絕提示，而不是悄無聲息地失效。需要整體移交業務簿時，請聯絡管理員或你的銷售經理。