fix(app-shell,plugin-detail): 记录页审批带渲染法定人数进度与会签分组 chips - #3163
Merged
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub. |
Contributor
✅ Console Performance Budget
📦 Bundle Size Report
Size Limits
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
缺陷
在业务记录页(
showcase_expense_report/AyG40_bAHSP_gi8T)上,审批面板的其它部分都是对的 —— 表头的 批准 / 驳回、Draft → Submitted → Approved → Reimbursed 管线、lockRecord的 审批中已锁定 徽标、撤回审批 —— 唯独法定人数进度和按组分片一个都不渲染。抓页面拿到的信号是:{"lockBadge": true, "approveBtn": true, "quorumHint": false, "groupChips": false}后果:
quorum节点上审批人看不到还差几票,per_group(会签)节点上看不到哪些组已签、哪些还欠 —— 恰恰是决定"我这一票是不是就把这一步走完了"的那个事实。根因(与 issue 的归因部分不符,以实测为准)
issue 说「服务端已经把需要的数据都发过来了,前端没消费」。结论方向是对的(framework 侧确实不需要改动),但"已经发过来了"这半句不准确 —— 对记录页这条链路,数据根本不在响应里。
实测追下来是这样的:
node_config_json(behavior/minApprovals/__approverGroups名单)算成一个decision_progress块 ——{ behavior, got, need, groups? },见plugin-approvals/src/approval-service.ts的attachDecisionProgress。这是服务端算好的、和引擎实际裁决规则同源的计数,客户端不该自己再推一遍。getRequest里挂(approval-service.ts:3634)。listRequests是故意跳过它的:每行都要额外查一次sys_approval_action做统计,而列表读可能返回几百行。useRecordApprovals,它读的是列表路由GET /approvals/requests?object=…&recordId=…。所以这条链路上decision_progress从来就没进过 payload —— 组件不是"忘了读",是拿到的对象里压根没有这个字段。顺带确认:审批中心(Approval Center 抽屉,
ApprovalsInboxPage)是渲染这两样的(objectui#2811 那次做的),因为它走getRequest。缺的只有记录页这一面 —— 这也解释了为什么同一条 checklist 里lockRecord那一半(#2906/#2914)好好的:lock_record是列表读就带的字段。所以这不是"服务端契约错了",也不需要在消费端加兜底掩盖上游 —— 服务端契约是对的,只是把这份富化放在了单条读上。正确的修法是让消费端去服务端实际发布它的地方把它读回来。
改动
1.
useRecordApprovals补一次单条读(packages/app-shell/src/hooks/useRecordApprovals.ts)列表读之后,只针对唯一那条 pending 记录再发一次
GET /approvals/requests/:id,把单条读的富化合并回该行。只有 pending 行才有活的计数、也只有它驱动表头,所以恒定一次追加请求,不会随行数放大。失败必须是无害的:请求出错、或返回的
id和请求的对不上,就原样保留列表行 —— 这是纯展示富化,一个 500 不能把审批面板带下去;更不能凭空编一个计数,错的 "1 of 2" 比没有更糟。2. 把它穿到审批带上(
@object-ui/react→@object-ui/plugin-detail)InlineEditProvider新增approvalProgress(类型ApprovalProgress),DetailView 的审批带在原徽标旁边渲染:quorum/unanimous:带role="progressbar"的标签 + 每一票一格的刻度条(Approvals — 1 of 2);per_group(会签):Sign-off — 1 of 2 groups,外加每组一个 chip 标出谁已签(finance 1/1✓ /manager 0/1)。渲染器保持 DataSource 无关 —— 计数由 host 从审批读里穿进来,组件不自己推导引擎的裁决规则。组名来自流程作者自己的配置(是数据不是文案),所以不需要为组名加任何 locale 字符串;新增的 3 个标签 key 已补齐全部 10 个语言包。
first_response节点不带decision_progress,行为完全不变 —— 那种节点一票即终局,"1 of 1" 的进度条是噪音不是信息。验证证据
新增回归测试,给定真实服务端载荷断言两样东西确实渲染 / 确实被读到:
packages/app-shell/src/hooks/useRecordApprovals.quorum.test.tsx(6 例)—— 载荷用showcase_committee_quorum(quorum,3 人名单minApprovals: 2)与showcase_expense_signoff(per_group,manager + finance)的真实形状:{ behavior: 'quorum', got: 1, need: 2 });/approvals/requests/req_committee_1;lock_record/pending_approvers等列表字段原样保留;groups[]与每个待审批人的pending_approver_groups都被暴露;decision_progress为undefined(不编造),且canDecide等既有能力不受影响;packages/plugin-detail/src/__tests__/DetailView.approvalBand.test.tsx新增 7 例 —— 断言渲染输出本身:Approvals — 1 of 2与锁定徽标并存;role="progressbar"(aria-valuenow=1/aria-valuemax=2)暴露,是可访问的语义而非装饰;lockRecord: false的可编辑节点同样渲染计数(进度关乎决策,不关乎锁);Sign-off — 1 of 2 groups+finance 1/1/manager 0/1两个 chip;first_response(无decision_progress)不渲染进度条 —— 老行为不变;闸门:
pnpm vitest run packages/plugin-detail packages/react→ 64 files / 682 tests 全绿pnpm vitest run packages/app-shell/src/hooks packages/app-shell/src/views/RecordDetailView→ 23 files / 210 tests 全绿pnpm vitest run packages/i18n→ 17 files / 157 tests 全绿(含 10 语言包全量 key parity)pnpm type-check→ 78/78 tasks 全绿eslint0 error(仅存量no-explicit-anywarning)未覆盖(另案)
issue 里还提到
sys_approval_request详情页把待审批人渲染成一串重复 user id 的逗号拼接。那是通用记录页渲染系统对象的问题(字段本身是 id 数组,没有 display 解析),和本 PR 的审批带是两条链路,未在此处一并处理。定级
changeset 定
minor:这是可观察的渲染输出变化,且在@object-ui/react上新增了公开的approvalProgressprop 与ApprovalProgress类型,不是既有面内的行为纠正。备注:提交历史
容器重启中断了本任务,协调方把当时未提交的 18 个文件抢救成了一条
wip: rescue …提交并首次推送了分支。按仓库纪律不做 force-push,故该提交信息保留在分支上;合并走 squash,落到main的是本 PR 标题与正文。Fixes objectstack-ai/objectstack#4478
Generated by Claude Code