Summary (QA row 561 / step 14.11)
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.
Summary (QA row 561 / step 14.11)
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:
Marking needs-info pending that decision; not auto-implementing.