Repository navigation
approvals UX: surface OOO/quorum/per_group/attachments SDUI-first — stop hand-editing the inbox per feature #2678
Description
Activity
P1 落地后的 UX 评估(实测补充,作为 P1.5 / P2 范围输入)
P1(#2681)浏览器实测中发现的真实体验问题,按影响排序:
- 两个决策面能力不一致(最实在):记录详情页记录头的 Approve/Reject(
useRecordApprovals)没有意见框、没有附件——从记录页可以零意见零附件批掉一单,合规场景是漏洞。根因:动作不是声明一份、两处渲染 → 正是 P2-4 的论据。 - 点击目标歧义:收件箱行内点记录名跳离收件箱去记录页(自动化测试第一次就踩中);"点行开抽屉 vs 点名跳走"边界太窄。
- 分组/quorum 进度不可见:per_group 抽屉只显示扁平 Waiting on 列表,看不出「manager 组已过 / finance 组待审」;quorum 无「2/3」。后端已快照
__approverGroups,数据在,UI 没用。 - 通知不深链:
actionUrl是笼统的/system/approvals,点进来还要自己找那一单。 - 附件 chip 无文件名(后端只存 fileId;时间线显示 "Attachment 1")。
- 抽屉记录上下文薄:摘要卡几个字段,看明细必须跳走(回到 2)。
- 移动端未验证(平台 gap Add @object-ui/types package - TypeScript protocol definitions #22;Sheet 在 <768px 未测)。
做得好的(保持):队列推进(批完跳下一单)、批量批准、j/k/a/r 键盘、快捷短语、SLA 逾期显示、空状态、角标。
P1.5(高性价比打磨,先做)
- 服务端计算的进度结构(framework 配套):
getRequest返回groups_progress: [{group, need, got, satisfied}]+behavior/min_approvals,客户端通用渲染 → 问题 3 治本,quorum/per_group/未来 weighted 全覆盖(SDUI:服务端算,客户端渲) - 通知深链(framework 配套):
actionUrl携带?request=<id>;收件箱识别 query param 自动开抽屉 → 问题 4 - 行点击目标:整行开抽屉,记录名保留显式外链 → 问题 2
- 时间线附件解析文件名(批量查
sys_file)→ 问题 5
P2(结构层,不变)
- P2-4 动作 SDUI 化同时治问题 1;P2-5 嵌套数组;抽屉记录上下文与移动端随 P2 一并处理。
Generated by Claude Code
- 两个决策面能力不一致(最实在):记录详情页记录头的 Approve/Reject(
- added a commit that references this issue
on Jul 19, 2026 分诊：关闭（duplicate） —— 审批面收敛为「#2763 治本 + #2762 打磨」两个入口，附否决窗口
本单的两半都已被更晚、更有裁决的单覆盖，继续保留会让同一件事有三个派发入口（查重收敛规则：一件事只留一个）。逐半核过：
一、P2 结构半边（收件箱动作 SDUI 化 / 嵌套数组）⇒ 已由 #2763 吸收
#2763 的方案是同一方向的更彻底版本（不止把动作声明化，而是整个收件箱与抽屉重建在
ListView+RecordDetailView+ApiDataSource上，删掉 bespoke 页面），且已拿到维护者 2026-08-03 的方向批准与排期（epic，v17 后，A2 先行）。本轮已给 #2763 落pm:on-hold+ 三要素。本单的 P2-4 若独立推进，会与它在同一批文件上撞车。二、P1 / P1.5 打磨半边 ⇒ 已转记到 #2762（本轮入队）
- 已由 PR fix(approvals): Approval Center UX pass — badge nowrap, approve confirm, progress bar, localized declared actions (#2762) #2789（2026-07-24 MERGED）交付：进度分段可视化 + 每组 ✓/○ + 可审批人计数（本单问题 3 的客户端半边）、决策确认（与本单「零意见批掉」相邻的那半）；
- 本单未被覆盖的四项（服务端
groups_progress结构、通知actionUrl深链、行点击目标歧义、附件 chip 无文件名）已逐条抄录进 审批界面(Approval Center)优化评估:徽章竖排 / 决策确认 / 进度可视化 / 动作标签 i18n #2762 的分诊评论，其中前两项标注为跨仓件（framework 侧，取用时走转移协议）。⇒ 没有信息丢失，只有入口合并。
三、四个能力的判定表已过期，不必再带着走
正文里 ①OOO（零代码）②委派（已存在）③quorum configSchema（自动渲染）三项当时就判为「已具备/零代码」，④决策附件已在 #2789 一族的
attachmentChip键位落地。剩下的是验证类工作，不是开发单。四、
⚠️ 一条没有跟着关闭的东西本单评论里那条最严重的观察 —— 记录详情页记录头的 Approve/Reject 没有意见框、没有附件，可以零意见零附件批掉一单，合规场景是漏洞 —— 已在 #2762 的分诊评论里显式点名并声明未并入，附上「若维护者认为不能等到 v17 后，可下轮单独立 P0 止血单」的路径。关闭本单不等于判定该缺口不存在。
⛔ 否决窗口
若认为 P2-5（流程设计器嵌套数组 / 切
SchemaForm.tsx）与审批无关、应独立存活（它确实是本单里唯一一条不属于审批面的诉求），重开本单或就那一条另立新单即可，本座位不会再次关闭。
本评论来自分诊座位 Routine（#5474 试点），不构成认领。
Generated by Claude Code
调研结论(代码级,file:line 均已核实)
平台的 SDUI 底座其实很强
packages/app-shell/src/hooks/useConsoleActionRuntime.tsx— 服务端声明的 action 按locations(record_header/list_item/list_toolbar/…)放置,按type分发执行(flow/script/api/form…),自带确认框/参数收集对话框/结果框 + token 解析。新增一个服务端 action = 前端零代码type:'object')→ObjectView免费渲染 list + form;@object-ui/fields已注册file→FileField(真上传部件)、lookup→LookupField(user picker)、datetime等FlowNodeInspector.tsx:113-120消费引擎发布的configSchema(ADR-0018/0019),经json-schema-to-fields.ts渲染:enum→select、number、array-of-object→objectListviews/metadata-admin/SchemaForm.tsx(2019 行)— 支持任意嵌套/数组/union/file/lookup,但只用于 metadata 表单,流程设计器没用它反模式根源:审批收件箱是手写的
apps/console/src/pages/system/ApprovalsInboxPage.tsx(1961 行)+ 私有 REST 封装services/approvalsApi.ts:Approve/Reject/Send back/Request info/Reassign/Remind/Recall/Resubmit 全部是硬编码<Button>+ 固定 handler,完全没走上面的动作运行时。这就是"每加一个审批能力都得改前端"的原因。SystemHubPage.tsx:1-17自己都注明:新管理面必须走 nav contribution,不要 bespoke page。四个能力的逐项判定
sys_approval_delegation+ Setup nav 项「Delegations (OOO)」;lookup(sys_user)/datetime/file 部件全有,ObjectView 直接可用。只需验证 + 截图ApprovalsInboxPage.tsx:1843-1849Reassign 按钮 + sys_user picker(:1376-1408, :681-691)→/reassignbehavior枚举 +minApprovals进 configSchema;json-schema-to-fields.ts的 enum→select、integer→number 无需前端改动。group文本列(objectList 行内可选 string)也已支持approvalsApi请求体只带{actor_id, comment};时间线不渲染附件(:1661-1683)。后端 REST 已支持attachments(#3268)方案(SDUI-first,两个阶段)
P1 — 立即可做(小)
flow-node-config.ts:416-509的硬编码审批节点 fallback 仍是first_response|unanimous两值 —— 与引擎 schema 已 drift。configSchema 存在时必须以 schema 为准;fallback 同步或标记弃用。FileField(复用packages/fields/src/widgets/FileField.tsx+RecordAttachmentsPanel的上传管线),approvalsApi.approve/reject/comment请求体加attachments: string[],时间线渲染附件行。做成可复用的 attachment-aware composer/timeline,之后审批线程的 payload 扩展不再新开 UI。P2 — 一次性通用投资(防止未来每特性改前端,本 issue 的重点)
sys_approval_request上服务端声明的 actions(type:'api'指向既有/approvals/requests/:id/*路由 + 类型化 params,如 reassign 的to: userpicker),由useConsoleActionRuntime渲染执行。收件箱页面保留布局/时间线,动作区改为读 action 元数据。此后新增审批动作(例如企业版 act-as、cloud#861)= 后端声明,前端零改动。(需 framework 侧配套:在sys_approval_request元数据声明这组 actions —— 协同小 PR)json-schema-to-fields.ts的columnsFor/FlowConfigColumn增加嵌套objectList/stringList列种(repeater-in-repeater);或SchemaForm.tsx,统一两套渲染器。任一使得未来引擎发布的任意嵌套节点配置(不止审批)自动可编辑。推荐先 a) 后评估 b)。
验收
attachments、时间线可见;复用 FileField关联
@objectstack/spec/ui的HttpMethod导出 ——@object-ui/types需迁移(一行,零形状变化) #3235 / chore(deps): Bump fumadocs-core from 16.13.0 to 16.14.0 #3255(OOO 委派,已合并)· framework#3266 / RecordDetailView 切换记录时不清空 feedItems:上一条记录的评论/活动会留在下一条记录的讨论面板上 #3268(quorum/per_group/附件,进行中)· framework#3267(引擎并行 ADR)· cloud#855/Dashboard右侧编辑器修改时左侧无法实时预览效果（排查所有导致Live Preview失效的原因） #861(企业版,将直接受益于 P2-4 的动作 SDUI 化)