Groups: user groups grant nothing, so wire them into access or remove them
- Dominant language
- C#
- Stars
- 6
- Forks
- 7
- Avg merge
- 4h 42m
- Merged PRs (30d)
- 307
Description
User groups can be created, nested and assigned, and they change nothing about what anyone can do. `User.GroupIds` (`barakoCMS/Models/User.cs:26`) is read only by the group endpoints themselves (`Features/Users/AssignGroup`, `Features/Users/RemoveGroup`, `Features/Users/List`, `Features/UserGroups/Delete`). `UserGroup` holds users and child groups and no roles or permissions (`barakoCMS/Models/UserGroup.cs`), and neither `PermissionResolver` nor the condition evaluator reads groups.
### Why it is too specific
It is half a feature that looks like a whole one. A school admin puts teachers in a Grade 5 group expecting them to see Grade 5; a clinic groups nurses by ward. The console lets them do it, nothing happens, and nothing says so.
### The general concept
Pick one. Either groups grant: a group holds role ids unioned into its members' roles, and conditions can test group membership. Or groups are removed and the member profile attributes planned for conditions cover the same need.
### Where it lives
Core: users, groups and permission resolution.
### Compatibility
Released surface. Wiring groups in is additive: existing groups hold no roles, so nobody's access changes. Removing them breaks the HTTP contract and the package surface (`User.GroupIds`, `UserGroup`), so it would go through `[Obsolete]` and an `ApiContract.Version` bump.
Part of the decision on what a principal is, linked from the umbrella issue.
### Done when
- The choice is recorded on this issue.
- If groups grant: a member of a group holding a role gets that role's permissions, with a test that fails before the change.
- If groups go: the endpoints answer with a deprecation header and a removal version.
Found in the architecture sweep of 15 September 2026.
Contributor guide
Research direction
Start with barakoCMS/Models/User.cs, barakoCMS/Models/UserGroup.cs, the group endpoints under Features/Users, PermissionResolver, and the condition evaluator; then read the linked umbrella issue. Decide whether groups grant roles or are removed, record that choice, and use the stated permission or deprecation criteria to define completion.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- csharp
- Domain
- authorization
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100