Heliosurge on ownership visibility and category permissions
That makes sense — I like the idea of the owner group showing up in the group directory with an “Owner” or “Managed by” label, similar to how category moderators are surfaced.
I think the distinction between:
- Full members (who receive badges, mentions, group flair)
- And owners via another group (who inherit permissions, but not identity)
…would be helpful to keep clear in the UI.
Example layout
Group @mentors
- Members: Alice, Bob, Charlie
- Owner Group:
@mentor-coordinators
Where clicking the owner group takes you to its membership list.
And I agree — for category permission purposes, it’s elegant to treat owner groups as “members” of the groups they own (to avoid needing to duplicate permissions manually).
Follow-up questions
- Would you see owner-group membership inheriting only for permission checks, or also showing up in things like group mentions and flair, if the owned group is public?
- Would it be possible for a group to own multiple other groups, or should there be a 1:1 ownership rule as a safety constraint?
Heliosurge on exclusive ownership model
Ah, got it — that’s a useful simplification.
So you’re suggesting that ownership should be exclusive:
- Either a group is owned by individual users
- Or it’s owned by a group (which contains the people with ownership)
- But you don’t allow both at once
That definitely keeps the model clean and avoids UI conflicts.
Hybrid workaround
If someone wanted a hybrid, they could always create an ownership group (e.g. @mentors-owners), include both individual owners and subgroup reps, and assign that as the sole owner group. Keeps things tidy without mixing ownership models directly.
Implementation questions
- Should this exclusivity be enforced at the database level (e.g. a group has either a
group_owner_id or a list of user_owners, but not both)?
- Or more of a UI-level convention with a warning?
- Should a group be allowed to be owned by more than one group (assuming no nesting)?
Heliosurge on category mod inheritance and owner hierarchy
That’s a helpful direction, thanks!
On category permissions inheritance
Yes — I was thinking of a situation where:
- Group B has post/reply/create access to a category (e.g.
#mentorship)
- Group A owns Group B
- So Group A inherits access to
#mentorship as well — without needing explicit category-level permissions
That would keep access management simpler if the ownership structure already expresses the trust boundary.
On category moderation
Good to know that Discourse now allows multiple groups to moderate a category.
Would you imagine the owner group of Group B also automatically gaining category moderator status for the categories Group B moderates?
That could help implement a tiered control model — where owner-groups can act as “head moderators” or “group stewards,” able to:
- Moderate across the same space
- Demote problematic group-level owners or sub-managers
Follow-up questions
- Would the inherited permissions apply only to category access/moderation? Or could they also cascade into other group-linked features (e.g. messaging, events)?
- In your tiered model, should the “top” group always be flat — or could it itself have owners?
This feels like it’s building toward a really flexible delegation model — helpful for schools, organizations, and structured online communities.