On my site I have a use case for people being given the privilege of managing group membership without being a member of the group themselves. I assumed this is how it worked and was surprised to see that someone I added as group manager is now also a group member.
The use case? We use groups to assign badges. And to give access to private categories. And the people responsible for doing this are not always group members.
Edit: having noticed this, I then removed some group owners only to realize they are still group members. Seems to me these should be managed independently.
We ran into this problem this week, too. (Although our groups represent a “group” membership outside of Discourse, too.) But that membership is not decided by a member of the group, and not by a Discourse admin, either.
Just ran into this very problem, where a group’s membership is not administered by a member of the group.
Our use case
We want a handful of non-Discourse-admins to be able to manage group membership for several groups without becoming members of those groups themselves.
This is probably asking too much, but I thought I’d throw it in… it’d be awesome if a group could be named as admin of another group (i.e., membership of the
@bar group can be managed by any member of the
@foo group). This would allow us to have a “group managers” group containing our non-Discourse-admins in charge of managing other groups’ memberships.
I just moved this to the #feature:voting category as I’d like it to be thrown into the mix for voting when that starts happening.
I like this idea! There is one person in charge of managing internal groups in my community but does not need to have admin privileges. It would be helpful to be able to set up a group for this so we can easily add/remove people to help her.
Another related feature that would be needed is the ability for group owners to see and manage the group even when “Group is visible to all users” is deselected. There should also be the option to allow group members, or members of a specific other group, to see the group.
Sure, I am open to disconnecting the two permissions.
Any chance the goal of “group owner does not need to be group member” with stretch goal of “group can be named as owner of another group” would be suitable for a GSoC project?
Very unlikely, way too small of a job.
Group can be owner of another group is not even something I would be comfortable adding.
Did anything come from the OPs request to separate group membership & group ownership? @sam supported the idea a while back (above).
Scenario: We added a moderator to a group, to manage group membership. However, this resulted in him getting the group’s badge displayed on his avatar.
Thanks for the reply, @Biscuit! I just came across this again in my community and the issue persists. In fact, it’s becoming a bit of a problem because certain leaders in my community complain that they are not trusted to properly manage the groups they are charged with managing. They have to ask an admin to add/remove people. I’m trying to keep down the number of admins (a conversation for another day).
It’s #pr-welcome so the discourse team have indicated they are open to having it done as a community contribution. Any takers?
It appears to me that with the new front-end groups management interface, there is no obvious place to list owners who are not members. Perhaps the answer is simply to just list them at the top, with the Owner badge but not the date added, posted or seen. And/or to list with a highlight color, as on staff posts?
Then the functionality to add owners could be a
+ ADD OWNERS button next to the existing
+ ADD MEMBERS button. Selecting this would pop up a modal to add one or more owners. On the list, if the REMOVE MEMBER button is selected and the member is an owner, the user would remain on the list as an owner but not as a member. If REMOVE AS OWNER is selected, the user would remain as a member but no longer as an owner (unless the user is not already a member and was only listed as an owner, in which case the user would be removed from the list entirely).
Unannotated screenshot for illustration.
We have the use case that there should be one master group that manages many smaller groups (~30 / i.e. @Archangels manage local Angel communities). They should not have to be members of all 30 groups, just be able to add/remove members.
We also run into this each time Google Summer of Code comes around. It also seems related to the various ideas about hierarchical/sub-groups, too.