docs(service): 把工单字段的三套分组与 Details 页签写实 (#958)

[yinlianghui]

Fixes #958

content/docs/service/cases 三语的两族失实：:55「详情屏幕分为 6 个分区」表与 :147「Details 页签有所有元数据字段」。src/ 零改动，纯文档。

一、stale-premise 复核：issue 正文有一条不成立

issue 说 Origin & Routing / Escalation / System 三个名字「在 src/ 里根本不存在，grep 零命中」。实测不成立：

src/objects/case.object.ts:18:    { key: 'origin',      label: 'Origin & Routing', ... },
src/objects/case.object.ts:21:    { key: 'escalation',  label: 'Escalation',   ..., defaultExpanded: false },
src/objects/case.object.ts:22:    { key: 'system',      label: 'System',       ..., defaultExpanded: false },

六个名字全部是 crm_case.fieldGroups 的 label（src/objects/case.object.ts:16-23，另有 src/translations/en.ts:688-694 的译文），连「两个默认折叠」都对得上（escalation / system 各带 defaultExpanded: false）。所以这张表不是凭空捏造的分区名，而是照抄了对象的字段分组、却挂到了「详情屏幕」名下。

这改变了改写口径：不是「点名说清不存在」，而是「点名说清它们是什么、真正归属在哪」——本 PR 按后者写。

issue 另一处小偏差一并更正：详情页 Description 分区只有 collapsible: true、没有 collapsed，所以是可折叠但默认展开，不是 issue 写的「默认折叠」（FormSectionSchema 里 collapsible / collapsed 是两个各自默认 false 的布尔）。

其余前提均复核成立：详情页 record:details 三个分区、表单 type: 'tabbed' 三个分区、description 归 Description 分区、parent_case 只在表单。

二、字段清点（本轮自己重数，未照抄 issue 数字）

• crm_case 声明 28 个字段（grep -cE "^ [a-zA-Z_][a-zA-Z0-9_]*: (Field|F)\."）。与 issue 一致。
• Details 页签 16 个（6 + 8 + 2）。与 issue 一致。
• 不在页签上的是 12 个，不是 issue 列的 11 个——issue 漏了 escalated_date（它用了「至少有」，属可接受的保守表述）。12 个已在正文逐一列出。
• 表单覆盖 24 个；fieldGroups 覆盖 27 个（priority_rank 不属任何分组）。

三、改了什么

:55 一段拆成三张表，各自标清出处：

方案	分区数	覆盖
对象 fieldGroups	6	27
详情页 record:details	3	16
表单 form（tabbed）	3	24

fieldGroups 那张表的六行里，原文有五行连「作为分组描述」都是错的（parent_case 属 basic 不属 origin、status / type 属 basic 不属 sla、closed_date 属 sla 不属 resolution、System 装的是 internal_notes / is_closed 而不是「审计跟踪、时间戳」——工单上没有任何叫「审计跟踪」的字段），只有 Escalation 一行原样正确。这些都按实况写出，不静默删名。

:147 从「所有元数据字段」改为「28 个里的 16 个」，并点名十二个缺席字段；其中 first_response_date 单独点出（同页上文刚用一整段讲它怎么打戳，读者顺着「所有元数据字段」去找必然扑空）。

四、渲染优先级依据

「六个分组在这两个界面上都不渲染」不是推断：objectui 的 resolveDetailSections（packages/plugin-detail/src/synth/buildDefaultPageSchema.ts）的次序是「显式 sections 优先 → 否则由 fieldGroups 推导 → 否则平铺」，而详情页与表单都显式声明了自己的分区。同一文件的 RecordDetailsComponentProps 也证实渲染器吃的正是本仓这种对象形式的 sections（{ name, label, fields, collapsible, collapsed }）。

五、验证

六道门在 flock -w 7200 /tmp/os-heavy-verify.lock 内串行，全绿：validate / typecheck / lint / hygiene / build / test 退出码均为 0（test：71 文件、1631 通过、1 跳过）。

守卫盲区如实说明：本次改动只碰 content/docs/** 与 .changeset/，六道门里没有任何一道会解析 MDX 正文的事实性断言（hygiene 对 content/ 只扫控制字节与文件体积）。所以改动前后都是 predicted GREEN，绿不构成对本 PR 正确性的任何证据——证据是正文里逐条给出的 file:line 实测。

推送前另做控制字节自扫：grep -naP '[\x00-\x08\x0b\x0c\x0e-\x1f\x7f]' 对三个 mdx 与 changeset 零命中。

未起 dev server。@objectstack/* 版本、content/docs/releases/、src/ 均未触碰；PR #939 / #946 / #947 / #956 的落地行零回退（diff 每文件只有 :55 与 :147 两个 hunk）。

六、范围外发现

已另立 #970（metadata + finding，未认领、未进队列）：crm_case 三套分组互不相同、escalated_date 三处写入零处展示，以及 layout: 'auto' / columns 字符串数字混用这一处 props 形状问题。与 #806（crm_lead 同病、不同对象）同族但非重复；上游 objectstack#5611 已 closed，未重复登记。

---

Generated by Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
hotcrm	Ignored		Aug 6, 2026 2:04pm