You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
question(user-mgmt): should contradictory group combinations be blocked? #1001
When assigning groups to a user, any combination is currently accepted, including contradictory ones (e.g. Viewer plus a higher-permission group). QA suggests adding logic so some group combinations cannot be selected together.
Open question (needs product decision)
In the group-membership-only authz model, permissions are the union of all the user's groups, so "Viewer + Admin" simply grants Admin (the union) rather than being contradictory. Before implementing any restriction we need a decision:
Should the UI actively block certain combinations (e.g. warn/prevent Viewer + a higher group), or is union-of-permissions the intended, sufficient behavior?
If blocking: what is the exact set of mutually-exclusive groups?
Marking needs-info pending that decision; not auto-implementing.
Product decision (owner): leave as-is. In the group-union authorization model, combining Viewer with a higher-permission group simply unions to the higher permission, so no combination is actually contradictory or a security issue. Blocking specific combinations would add UI friction for no behavioral benefit.
Closing as wont-do. The distinct validation-UX work (invalid-input feedback) was handled separately by #1405 / PR #1427. QA sheet row 564 will be marked not-a-bug / Ready to Test.
Activity
feat(user-mgmt): clarify group permissions combine via union (closes #…
cristim commentedon Jul 17, 2026
Product decision (owner): leave as-is. In the group-union authorization model, combining Viewer with a higher-permission group simply unions to the higher permission, so no combination is actually contradictory or a security issue. Blocking specific combinations would add UI friction for no behavioral benefit.
Closing as wont-do. The distinct validation-UX work (invalid-input feedback) was handled separately by #1405 / PR #1427. QA sheet row 564 will be marked not-a-bug / Ready to Test.