- Ya
- 28 Agosti 2026, 00:50 UTC
- Mwandishi
- Kamo
- Ahadi ya
- 266357d
Three changes that turned out to be one. THE HOME PAGE. "My Master Note" and "Our Master Note" were bespoke panes rendered straight out of page.tsx, gated on nothing, positioned by their own layout ids, and removable by nobody — so a member whose role withholds VIEW_NOTES had no Notes icon, no /notes page, and two notes on their home page anyway. They are registry widgets now, which is what the registry says it is for: one entry buys the grid, the drag, the ordering, the per-member show/hide, the settings screen and the five-right policy. There is no master-note code left in page.tsx. Their layout ids change from master:mine / master:ours to widget ids, so a member who had dragged those two panes somewhere finds them back at their default place once; a permanent two-pane mapping in the layout store would have been the worse trade. The pinned-note panes were already gated on the nav's answer; that answer now lives in one place (lib/notesAccess) rather than being spelled inline. THE GROUPS. A security group is an APP, shown only when the organisation has that app switched on — that gating is the whole reason groups exist. Apps have been a two-level tree since 2026-08-24 and the groups now follow it: POS is "Lines of Business" (was "Commerce") with Retail, Rentals, Service Work, Subscriptions, Procurement, Mortgage Lending, Personal Lending and Patient Records under it. The group list was hand-maintained and had fallen behind the catalog, which is worse than it sounds: a right whose serviceType matches no group cannot be granted in any editor and nothing says so. Meetings, Mortgage Lending, Personal Lending and Games were in that state — 19 rights, ungrantable however the app was licensed. It is now a COVERAGE test: permissionAppSections.test.ts reads RoleRightType.java and fails if any app with rights has no group, and reads ServiceType.java's parent(...) line to pin the nesting. Two more of the same shape, found on the way: the job-title and department editors dropped the five Access Security rights and CONFIGURE_SYSTEM entirely (carved out of General into groups neither editor rendered), and the member tab titled its groups with the raw enum name — "POS" here, "Commerce" three screens away. Every editor now builds its groups through permissionGroupTree, so none of them can hold a different taxonomy again. THE UI. Four screens rendered ~280 rights as a stack of accordions — one column about nine screens tall, where finding "can this role refund an order" meant opening accordions in turn. And the stack is flat, which the apps no longer are. So it is a console: a rail of groups, nested as the org's apps are, beside a panel showing one group. Each rail row carries a granted-against-total meter for its whole subtree, so the shape of a role is legible before anything is opened — a Support Agent four-fifths of the way through Patient Records is visible from the rail. Search spans every group with per-group hit counts; the rail is sticky, arrow-key navigable and becomes a scrollable strip below md; reduced motion is respected. One thing that had to be fixed rather than inherited: splitting commerce into child groups broke the cascade, because denying ACCESS_COMMERCE under "Lines of Business" would no longer nuke VIEW_SUBSCRIPTIONS under "Subscriptions". RightsSection takes a `context` prop now — every right in every group — so the cascade works on the whole tree while only one group renders.