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).
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@1ee48bc60against the published@objectstack/console@17.0.0-rc.1(pin7d9734d5e321).The server publishes everything the quorum UI needs; the Console renders none of it.
What the server sends
The showcase's
showcase_committee_quorumdemo request carries, onsys_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-approvergrouplabels (theshowcase_expense_signoffrequest carries"group":"manager"/"group":"finance"withbehavior:"per_group"), and even a pre-rendered__nodeLabelreading "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 forlockRecord, 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 thesys_approval_requestdetail 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
quorumnode an approver cannot see how many more approvals are needed, and on aper_groupnode they cannot see which groups have signed and which are outstanding — the two facts that decide whether their own decision completes the step. ThelockRecordhalf 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).