feat(matrix): business roles off the rows by default, with a wizard option to fold them back in (#370 + #937)

[fortigi-ci-bot]

Closes #370. Also carries and closes #937 — the two were merged into one item at the requestor's request; #937's PR (#1183) and the interim stacked PR (#1184) are closed in favour of this one.

What you get

#937 is the default. Business roles and access packages are no longer resource rows: they are governance intent and already appear as the business-role columns, so the same role stopped showing up on both axes at once.

#370 is the option. The wizard's Resources step gains "Show business roles as foldable rows", off by default and saved with the matrix (so a shared or saved matrix renders the same for everyone). Tick it and you get the whole layer:

• each business role on a row of its own, with the resources it grants drawn underneath it — indented, same triangle and elbow as an expanded nested group — and the role directly above them in the row order;
• fold a role to hide those rows, leaving an "N resources folded" chip; Fold roles / Unfold roles does every role at once, reducing the grid to "business roles + resources no role grants". Fold state is remembered per matrix;
• a resource several roles grant appears under each of them, with a BR / BR+3 chip that counts and names the others;
• markers for both directions of drift — fewer than the role assigns, more than it assigns, and held outside the role that grants it — on the resource rows and rolled up onto a folded role;
• the Excel export mirrors that structure, always unfolded, so folding can never leave access out of a review file.

Leave it unticked and the matrix is what it was before, minus the business-role rows.

How the option is enforced

The gate is the data, not a pile of UI conditionals. With no business-role rows on the resource axis, analyseRoleRows finds nothing foldable, no row carries a roleParentId, and every affordance disappears on its own.

Two things could have been drawn from the SOLL columns alone, so they take an explicit showBusinessRoles: the red + "more than the role assigns" mark, and the legend entries for markers a default grid can never draw. That makes "the default matrix is the old matrix" a property tests pin rather than an emergent one — see the new describe blocks in MatrixView.mount.test.jsx, MatrixGroupRow.mount.test.jsx, MatrixLegend.test.js and matrix-business-role-rows.spec.js.

Migration 061 vs #937's decision 5

Reconciled without a flag of its own: the coverage view's self arm stays unconditional (holding a business role is governed access), and the scope/governed counts follow the option because the resource axis does — #937's choke point already keeps business-role resources out of the pair counts. Pinned from both directions in scopeHistory.test.js.

Rebuilt, not merged as-is

This branch was force-pushed onto a rebuild against current main, which has since extracted accessPackageModel.js, MatrixCell.helpers.js and the row-cell components — so the fold, the staircase promotion and the marker strip land in those instead of in the monolith they were written against. The previous implementation stays readable in this PR's earlier commit range.

Not gated, on purpose

Two things here are not about business roles and stay on for everyone: the resizable grid (useViewportFitHeight / useResizableGridHeight / GridResizeHandle, which also fixes a page-overflow the current measurement has), and the cell marker strip geometry that stops markers overlapping their neighbours' badges. One behaviour change does reach the default matrix: the Gaps row filter now uses the same comparison as the amber !, so the Gaps view and the marker can no longer disagree.

Tests

• UI 1522 passed, API 2735 passed against current main merged in (incl. the vitest 5 bump).
• Both coverage suites green against their thresholds.
• New mutation scope app/ui/stryker.roles.config.json for coverageDeviation.js + useBusinessRoleFold.js — measured 93.54%, floor 90, registered in the weekly workflow. The five presentational/measurement files that landed with the feature are excluded with written reasons.
• The two Python ratchets (file length, complexity) could not be run locally — no working interpreter on this box — so CI is the first check there.

🤖 Generated with Claude Code

[github-actions]

🤖 Built + verified on dev-docker-03. e2e on the live env + full CI green. Functional testing: https://3.build.identityatlas.io. Awaiting requestor acceptance on #370.

[WimvandenHeijkant]

Superseded by #1184, which rebuilds this work on top of #937 (#1183) and puts the whole business-role row view behind that PR's wizard option — default off, so the matrix stays as it is on main unless a matrix asks for the layer.

Closed unmerged on purpose, per the scope amendment on #370: this branch was written against a main that has since extracted accessPackageModel.js, MatrixCell.helpers.js and the row-cell components. Its implementation stays reachable in the history of dor/issue-370 as the reference it was.

Note for whoever watches the pipeline: the dor-reset leg for this PR is dispatched to sk3, whose runner is currently registered offline, so the sidekick wipe will sit queued until that runner service is back up. The box itself is up and still serving this build at 3.build.

[WimvandenHeijkant]

🚀 Deployed to dev-docker-03 for functional testing → https://3.build.identityatlas.io (Fortigi-tenant sign-in via authentik). Serving dor/issue-370 at 5fd87ff, version 5.663.20260912.1231.

Put there by hand rather than by the deploy-to-sidekick label: that workflow dispatches to whichever dor-build runner is idle and every other box in the pool is reserved, so there was no way to aim it at sk3. The sk3 runner itself had been crash-looping since 2 September on a half-finished self-update to 2.337.0 (System.Xml.ReaderWriter failing to load) — its binaries have been re-extracted and it is connected and listening again, with bin.2.336.0 left in place as a fallback.

What to check

Default (no option ticked) — this should look like the matrix you already know, minus the business-role rows:

• no business roles among the resource rows, but the business-role columns and their colouring unchanged;
• no "Fold roles" buttons, no BR chips, no red markers; the legend lists only the markers the grid can draw;
• resource/assignment counts and the scope panel count what is actually rendered.

Then open the wizard → Resources step → tick "Show business roles as foldable rows":

• each role gets its own row with the resources it grants underneath it; fold one with the chevron, or all of them with Fold roles;
• a resource two roles grant appears under both, each copy carrying a BR chip;
• a folded role keeps a red and an amber count per subject for access it does not cover and access it assigns that is missing;
• Export Excel: the file mirrors the grid but always unfolded.

The option is saved with the matrix, so a shared link renders the same for whoever opens it.

[WimvandenHeijkant]

CI is green on 1c91a4f: 32 passing, 2 skipped, nothing failing. https://3.build.identityatlas.io now serves this exact commit (redeployed after the two fixes below), so what was validated is what merges.

Two things needed fixing after the first green-on-my-machine run, both worth knowing about:

The complexity ratchet caught MatrixView at cyclomatic 22 against a ceiling of 20. The opt-in added four decision points to an orchestrator already at the limit. Rather than golfing them away, the business-role layer moved out into useMatrixBusinessRoleLayer — the flag, the fold, the export-row choice and the deviation tallies as one named thing the grid switches on or off, next to the column model and the nested-row builder that left MatrixView for the same reason. It ships with tests about the switch rather than the pieces it composes: off, the rows come back untouched, the export is the plain row order, there are no tallies; and a truthy-but-not-true flag (a string "true" off the wire) leaves it off, matching the API parser.

The grid-resize e2e pinned a pixel snapshot across a reload. It compared the height after "Fit to window" against one taken before the drag. That fit is measured from the chrome above the grid, and the chrome is not identical after a reload with a custom height in place — the two retries of the same click read 403 and 445 against an expected 250. It now asserts what the button promises: the chosen height is dropped (button gone, nothing left in storage) and the grid is measured again, still with exactly one scroller. A reset that failed to clear the stored height fails all three.

Unrelated finding, flagged rather than fixed here. main's vitest 4 → 5 bump (#1185) breaks Stryker's per-test coverage repo-wide. My roles scope measured 93.54% under vitest 4.1.11; under 5.0.0 it reports 23.16. That is not this branch: the untouched stryker.pilot.config.json, documented and floored at 91 from a measured 93.8, now reports 18.07 with usePermissions.js flat at 0.00 while its own suite is green. Every scope in the weekly js-mutation.yml will be red until that is sorted (a Stryker release that supports vitest 5, or coverageAnalysis: "all" as a stopgap). I left the roles floor at the real measurement and wrote the reason into the config — please don't re-baseline any floor to a vitest-5 number, that would bake the outage into the ratchet permanently. Mutation testing does not run on PRs, so it does not block this merge.

[github-actions]

♻️ PR merged. Reset dev-docker-03 (stack down, volumes + images pruned) and released it back to the dor-build pool.