Permission Matrix Inheritance Preview

Large Theory

Permission management usually fails not because one toggle is missing, but because users cannot explain where effective access comes from. Roles, groups, teams, spaces, projects, repositories, global permissions, and object-level permissions can stack. If the UI only shows checkboxes, admins cannot tell why a user can delete, invite, export, change billing, or administer security. A healthy permission matrix keeps source, inheritance path, override rules, dangerous capabilities, and save impact in one review flow.

Small Points

1. Separate object levels first: organization, space/project/repository, team/group/role, user, resource, and capability.
2. Each cell shows final state and source: direct, role, group/team inherited, default, external guest, denied, pending invite, or system locked.
3. Dangerous permissions are labeled and grouped separately, such as billing, delete, export, invite external, change security policy, and manage roles.
4. Preview the diff before saving: which users, groups, and resources gain or lose access, whether notifications fire, whether approval is needed, and whether an audit log will be written.
5. A single-user detail view should expand source paths and exceptions so admins do not infer inheritance from a large table.
6. The matrix needs keyboard navigation, row and column headers, frozen first column/header, search, filtering, and accessible names. State cannot rely only on color or icons.

Design Judgment

The matrix is trustworthy when admins can answer why a person has a permission, who a change affects, whether it can be rolled back, and who may save it. If the page is only a grid of checkboxes, the save button becomes a security risk.

Implementation Notes

Create a permission change model: subject, subjectType, resource, scope, capability, currentEffectiveState, sourcePath, requestedState, riskLevel, approver, notificationImpact, and auditReason. The frontend can use a table or virtualized matrix, but the preview panel, dangerous-permission confirmation, bulk diff, and audit reason should be mandatory before save. Batch operations disable row-level actions, and the saved state should show an audit id plus rollback path.

Counterexamples/Risks

All permissions use the same checkbox, inherited access looks like direct access, dangerous permissions are hidden in ordinary columns, bulk save has no diff, external guests and internal members are mixed, roles are shown without resource scope, and keyboard users cannot identify row/column relationships.

Case Study

Atlassian's Jira permission materials separate global, space, and work item permissions and explain that permission schemes are assigned to specific spaces. GitHub documentation separates repository access from organization roles and supports granular repository roles. Carbon Data Table guidance shows a batch action bar after row selection and disables row actions while batch mode is active. The reusable lesson is that permission UI must express hierarchy, object scope, and bulk-change state together rather than copying a generic data table.

Source Links

Atlassian Jira permissions overview: https://www.atlassian.com/software/jira/guides/permissions/overview Atlassian permission schemes: https://support.atlassian.com/jira-cloud-administration/docs/what-are-permission-schemes-in-jira/ GitHub repository roles: https://docs.github.com/organizations/managing-user-access-to-your-organizations-repositories/repository-roles-for-an-organization GitHub managing repository access: https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/managing-repository-settings/managing-teams-and-people-with-access-to-your-repository Carbon Data Table: https://carbondesignsystem.com/components/data-table/usage/