Console approvals: quorum progress and per-group chips do not render, though the server sends minApprovals / group / __nodeLabel

[baozhoutao]

Found while verifying the 17.0.0-rc.1 checklist on #3909 (section C — "Approvals UX: quorum progress, per-group chips (objectui#2811)"). Verified in the browser on main @ 1ee48bc60 against the published @objectstack/console@17.0.0-rc.1 (pin 7d9734d5e321).

The server publishes everything the quorum UI needs; the Console renders none of it.

What the server sends

The showcase's showcase_committee_quorum demo request carries, on sys_approval_request.node_config_json:

{"approvers":[{"type":"position","value":"manager"},
              {"type":"position","value":"finance"},
              {"type":"position","value":"legal"}],
 "behavior":"quorum",
 "minApprovals":2,
 "lockRecord":true,
 "onEmptyApprovers":"admin_rescue",
 "__nodeLabel":"Committee Sign-off (2 of 3)",
 "__approverGroups":{ … }}

behavior, minApprovals, the per-approver group labels (the showcase_expense_signoff request carries "group":"manager" / "group":"finance" with behavior:"per_group"), and even a pre-rendered __nodeLabel reading "Committee Sign-off (2 of 3)".

What renders

On the business record (showcase_expense_report/AyG40_bAHSP_gi8T) the approval panel is otherwise complete and correct — 批准 / 驳回 in the header, the Draft → Submitted → Approved → Reimbursed pipeline, a 审批中已锁定 badge for lockRecord, and 撤回审批. Scraping the rendered page for the quorum signals:

{"lockBadge": true, "approveBtn": true, "quorumHint": false, "groupChips": false}

No 2 / 3, no progress indicator, no group chips — neither on the record's approval panel nor on the sys_approval_request detail page (which renders as a generic record page: status pills, request id, flow run/node, and 待审批人 as a raw comma-joined string of repeated user ids).

Consequence

On a quorum node an approver cannot see how many more approvals are needed, and on a per_group node they cannot see which groups have signed and which are outstanding — the two facts that decide whether their own decision completes the step. The lockRecord half of the same checklist line (objectui#2906/#2914) does render, so this is specifically the quorum/group progress surface.

Filed against the framework tracker since #3909 is where it was found; the fix belongs in objectui (#2811). No framework-side change appears needed — the data is already on the wire.

Part of the #3909 rc.0/rc.1 verification (section C).

[baozhoutao]

Tracked under the v17 verification tracker #3909 (section C).

[baozhoutao]

Rolled up in #4482 (all 17 defects from the v17 verification, grouped by severity with a suggested RC-exit triage).