Repository navigation
allow groups to be member or admin of other groups #36150
Copy link
Copy link
Open
Labels
0. Needs triagePending check for reproducibility or if it fits our roadmapPending check for reproducibility or if it fits our roadmapenhancementfeature: users and groups
Description
Activity
- added0. Needs triagePending check for reproducibility or if it fits our roadmapPending check for reproducibility or if it fits our roadmap
on Jan 16, 2023 - added 9 commits that reference this issue
on Apr 10, 2026 - added 9 commits that reference this issue
on Apr 22, 2026 - added a commit that references this issue
on May 10, 2026 Thanks @KiaraGrouwstra for working on this! I support this use-case, working on a Nextcloud instance that hosts multiple local groups. Now each group mutation results in a request to the central administrators. A decentralized authorization model would match other platforms in use, like Matrix chatrooms where you can have admins and moderators per room. That decentral model is empowering and there are certainly situations where it is a more fitting model.
Reacted by kiara and jameskimmel
Metadata
Metadata
Assignees
Labels
0. Needs triagePending check for reproducibility or if it fits our roadmapPending check for reproducibility or if it fits our roadmapenhancementfeature: users and groups
Is your feature request related to a problem? Please describe.
our organization has teams administering other teams, tho not administering the entire server.
therefore, it would seem desirable to let people of the super-team administer the sub-teams and their members.
as the members of the super-team may change tho, it would seem desirable to assign these rights on the level of the super-group, rather than of its individual members.
however, as it stands, it seems only individual users may be assigned member or admin status in a group, whereas other groups may not.
Describe the solution you'd like
allow groups to be member or admin of other groups
Describe alternatives you've considered
giving the super-team their own instance of stuff they administer, and apply some federative relationship with the original instance such that super-team members don't get too many rights over others.
Additional context
relationships between entities of the same type (in this case: groups) seems like the kind of thing generally tackled using graph databases rather than relational ones. as such, solving this without architectural adjustments may be non-trivial.