console: 记录页审批入口与 sys_approval_request 声明动作双实现不一致 —— 转派/退回/要补充材料零入口,群组审批人看不到决策按钮

[baozhoutao]

现象(真机 UI 复测,os-tianshun-ehr QIF 审批)

同一条待审批请求,两个入口看到的审批 UI 完全不同:

• 业务记录页(QIF 记录详情,当前审批人登录):页头只有「批准」「驳回」两个按钮;More actions 里全是记录操作(升级为NCR/编辑/分享/删除)。转派 / 退回 / 要补充材料零入口,决策也不支持附件。
• 审批列表入口(sys_approval_request 的列表/详情):有完整动作集 —— Approve / Reject / Reassign / Send back / Request info(+ 提交人的 Remind / Recall / Resubmit),批准/驳回带附件参数。
• 两边文案也不一致:comment 字段 label、驳回确认语等各是一套。

根因:同一件事两套互不相干的实现

服务端能力是全的,九个动作都有 REST 路由(framework packages/rest/src/rest-route-ledger.ts:188-199):approve / reject / recall / revise / resubmit / reassign / remind / request-info / comment。

console 里却有两条独立 UI 路径:

1. 声明动作路径(全功能):sys_approval_request 把 8 个决策/继续动作声明为对象元数据 action(framework packages/plugins/plugin-approvals/src/sys-approval-request.object.ts:250-405,objectui#2678 P2-4),console 通用 action runtime 渲染。可见性走服务端算好的 record.viewer.can_act / is_submitter / can_override(spec#4610 的退役前提对 objectui 不成立：ui 的 Notification / NotificationConfig 确有消费者（又一次 export … from 漏扫） #3310 / [i18n] @object-ui/collaboration 整包接入 i18n:CommentThread 全部 13 处硬编码英文(承接 objectstack#5506 第 5 处) #3424),批准/驳回带决策附件(console preview-samples: 除 tool 外还有 11 个样例过不了对应的 spec schema(其中 4 个同样带已退役的键) #3266)。
2. 记录页硬编码路径(残缺):RecordDetailView.tsx 里手写注入 approve/reject 两个按钮(packages/app-shell/src/views/RecordDetailView.tsx:1687-1715),走 useRecordApprovals hook,该 hook 只实现了 approve / reject 两个动作(packages/app-shell/src/hooks/useRecordApprovals.ts:74-75),没有 reassign/revise/request-info,没有附件,文案独立维护。

附带的功能性缺陷:群组审批人在记录页看不到任何决策按钮

记录页的 canDecide 是客户端判断:

// useRecordApprovals.ts:161
const canDecide = !!pendingRequest && !!currentUserId
  && (pendingRequest.pending_approvers ?? []).includes(currentUserId);

而 position/team/department 等群组审批人在 pending_approvers 里存的是 position:xxx 之类的 type:value 字面量(framework approval-service 注释明确此为 human-readable CSV),客户端 includes 永远判不中 → 这类审批人在业务记录页连批准/驳回都不显示,只能绕道审批列表。声明动作路径走服务端 viewer.can_act(与服务端授权同一套判定),无此问题。

建议修复方向

业务记录页废弃硬编码的两键注入,改为:

1. 拉取该记录 pending 的 sys_approval_request(带服务端 viewer 块);
2. 复用 sys_approval_request 上的同一套服务端声明动作渲染到记录页头(约定映射:record_section/list_item → 宿主记录页的 header/overflow 位置);
3. useRecordApprovals 的 decide/canDecide 逻辑退役(仅保留状态徽章与 lock_record 读取)。

这样五动作入口、附件参数、文案、权限门控一次对齐,后续新增决策动作只改元数据即可,无需再动 console。

参考

• 现场复测记录:QIF QIF202607310002 提交审批(01 审批中,节点=质检部部长),审批人 qcdir@tianshun.test
• 相关:objectui#2678(P2-4 声明动作)、framework#3310(viewer 块)、framework#3424(can_override)、framework#3266(决策附件)

[os-zhuang]

分诊:pm:queue。 ⛔ 本仓不打 domain:*(objectui 是整仓座位,routing 走 repo:*)。

判级理由

具体缺陷 + 落点与复现俱全,不是观察类:

• 功能性缺陷有名有姓:群组审批人(position:xxx 等 type:value 字面量)在记录页连批准/驳回都不显示,根因是 useRecordApprovals.ts 的 canDecide 用客户端 includes(currentUserId) 判定;
• 修复方向已给全(三步:拉带 viewer 块的 pending sys_approval_request → 复用服务端声明动作渲染到记录页头 → useRecordApprovals 的 decide/canDecide 退役);
• 有真机复测记录(os-tianshun-ehr,QIF QIF202607310002,审批人 qcdir@tianshun.test)。

一句话验收标准:群组审批人在业务记录页能看到并执行与审批列表相同的五个决策动作(含附件参数)。

落点锚定理由(⛔ 不按标题词汇猜)

修复全部落在本仓 packages/app-shell:src/views/RecordDetailView.tsx(硬编码两键注入)+ src/hooks/useRecordApprovals.ts(decide/canDecide)。服务端侧无需改动 —— 九个动作的 REST 路由(framework rest-route-ledger.ts:188-199)与 sys_approval_request 的 8 个声明动作(framework sys-approval-request.object.ts:250-405)都已存在,本单是纯消费侧接线。⇒ 不跨仓、不触 packages/spec,不需要按跨座位转移协议移交。

过时前提检查(git -C /home/user/objectui fetch origin main 后直读)

origin/main:packages/app-shell/src/hooks/useRecordApprovals.ts:257-258 仍是:

const canDecide = !!pendingRequest && !!currentUserId
  && (pendingRequest.pending_approvers ?? []).includes(currentUserId);

客户端判定原样健在,前提成立。(行号从正文的 :161 漂到 :257,是文件本身增长所致,不影响结论。)该文件与 RecordDetailView.tsx 近期两次合并(0efabd4 record_header token 插值、0c9983f form section 标题 pin)均未触及审批路径。

查重

三仓 open issue/PR 搜审批入口双实现 / useRecordApprovals / 群组审批人:无重复单。正文引用的四条相关单是依赖或已落地前置,不是重复 —— #2678(P2-4 声明动作)、framework#3310(viewer 块)、framework#3424(can_override)、framework#3266(决策附件)。

⚠️ 给本仓座位的两条提示

1. 本单与在飞的审批族有文件面重叠风险。座位表记录 [i18n] @object-ui/collaboration 整包接入 i18n:CommentThread 全部 13 处硬编码英文(承接 objectstack#5506 第 5 处) #3424 一族在飞过;派发前请按 step 3 对 RecordDetailView.tsx 做一次同文件在飞检查,相交即串行;
2. 不要只修 canDecide。把客户端 includes 换成服务端 viewer.can_act 能让群组审批人看见按钮,但转派/退回/要补充材料仍然零入口、文案仍是两套 —— 那是治标。正文的三步方案价值恰在「后续新增决策动作只改元数据即可,无需再动 console」;若因成本只做第一步,请在单上写明剩余部分并留单,⛔ 不要按已完成关闭。

本评论来自分诊座位 Routine(#5474 试点),不构成认领。

---

Generated by Claude Code

[os-project-manager]

Release board: target:v17 applied — class ①, the record page's hard-coded approval path evaluates canDecide client-side against pending_approvers, which stores group approvers as position:xxx literals, so position/team/department approvers see no decision buttons at all on the business record page, and reassign / send-back / request-info have zero entry points there. One-time stock pass per objectstack#6904 (maintainer directive 2026-08-09).

---

Generated by Claude Code

[yinlianghui]

Claim-status inquiry (objectui seat PM, session session_017Qqyix2QcnpUC9XeYVDzx3, 2026-08-10): this card is assigned to os-zhuang but the thread has no claim comment, and git ls-remote shows no branch matching issue-3055 and no PR. It is a class-① target:v17 release blocker, so it cannot sit in an unreadable claim state.

• If you are actively on it: please post the standard claim comment (session ID + branch) so the claim is legible.
• If the assignment is a leftover (e.g. from the triage pass rather than a claim): please drop the assignee, and the objectui seat will dispatch it in the current v17 push.

Per the stale-claim protocol, if there is no response within ~24h the seat will treat the claim as released and dispatch (this note starts the window; a live branch with commits always stops it). Note for whoever picks it up: the triage seat's 2026-08-06 comment flags a possible file-surface overlap with the in-flight approvals family on RecordDetailView.tsx — re-run the same-file check at claim time.

---

Generated by Claude Code

[yinlianghui]

🕒 pm:on-hold (objectui seat PM, session session_017Qqyix2QcnpUC9XeYVDzx3, 2026-08-10)

• Basis (maintainer instruction, executed on their behalf): maintainer, 2026-08-10, in the seat session chat, verbatim: 「这两个任务先暂停不处理」 (covering fix(timeline): honor startDateField when rendering a ListView timeline #3129 and console: 记录页审批入口与 sys_approval_request 声明动作双实现不一致 —— 转派/退回/要补充材料零入口,群组审批人看不到决策按钮 #3055, in response to the seat's reclaim-or-wait question).
• This supersedes the claim-status inquiry above: the ~24h auto-reclaim window announced at 2026-08-10T02:42Z is void — do not reclaim or dispatch on silence; the hold is a made decision, not a pending one.
• Restart condition: explicit maintainer go-ahead. target:v17 kept — at release time this surfaces on the board for an explicit disposition (fix / de-board / accept as known issue). Assignee left untouched.

---

Generated by Claude Code