Group owners should not necessarily be group members

Feature
23

Really appreciate the clarification, Dan — limiting group-to-group ownership to one level deep makes a lot of sense for maintainability and avoiding privilege creep.

I like the idea that:

  • Group A owns Group B → members of A get owner rights on B
  • Group B owns Group C → members of B get owner rights on C
  • But Group A is not an owner of C — only transitively a member (not manager)

That helps avoid infinite nesting while still supporting useful delegation structures.

Also agree that limiting ownership depth via a group_ownership_nesting_level setting (like subcategory nesting) gives sites flexibility — maybe default to 1, but allow opt-in to deeper control if needed.

A few clarifying questions I had:

  • In your model, should the owning group appear as a member of the owned group in the group directory UI? Or is the membership purely permission-based?
  • If a group has multiple owners (some users, some groups), how do you see conflict or redundancy being resolved in the UI?
  • Would ownership affect category permissions at all (e.g. could the owner group manage the category tied to the owned group)?

This would open up a lot of flexibility in education, org, or project-based forums — thanks for keeping the idea moving!

2 Likes