@jmay That is great news! Unfortunately I not only have no Ember skills,
but my HTML, CSS & JS are weak as well. :{
We will be able to get to this probably sometime this year, though I don’t know exactly when. So don’t worry, if nobody from the community steps up, your work will not be in vain! I assure you 
3 Likes
Saw that the group ownership feature was added today and am super happy about it! Thanks for the time on this one, it’ll be very helpful for running my forum. 
Quick q - is it possible to have the group owner not be a group member?
We have basically two use cases for this feature:
- The group owner is also the group leader, and so being a group member makes perfect sense
- The group owner has some responsibility for managing the group, but is not otherwise part of the group (e.g. a ‘boss’ role person managing a ‘minion’ group)
It’s something we can work around but it’s a little messy, largely because one of the groups we want managed has a default title and trust level assigned. This works great normally, but doesn’t gel as well with situation number 2 up there.
A couple other things I wanted to mention as (areas for) potential future improvements:
- The public group UX is a bit hard to find (my forum doesn’t heavily use titles, at least for group-membership, and even then it’s a bit hidden). The new group owners are going to learn about it soon enough, but it’d be nice if this was more prominent/accessible
- Supposing that group owner w/o group membership is possible: automatically assigning group owners based on membership in a separate group would be useful
So! Still quite happy with the addition, thanks again.
4 Likes
It would be good if /groups went to a list of groups, instead of having to go via user profiles.
But still, this is very useful 
EDIT: And will be even better when @@group mentions are updated
I am not sure I agree with allowing people the role of owner without group membership. It’s not providing any security as the user can easily just add a sock account to the group to snoop around. There is no security benefit.
Allowing a TL1 user to manage a group of TL4s also seems rather odd as a requirement.
The title issue is easily worked around by providing a title to the particular owner prior to giving group membership.
Originally this was implemented in such a way that ownership and membership was totally decoupled, but it felt really odd to me.
2 Likes
I agree that just assigning a custom title (and trust level, in those rarer cases) to special roles makes the most sense. Then it’s up to you whether you want this person to also be part of the group or not, depending on your organisational needs.
Decoupling would also leave more room for confusion when it comes to things like group listings and @mentions. It’s unnecessary cognitive load for the user. Say I try to get the attention of @ux-team. All the team members except the manager got the notification? why?
Coupling necessitates the occasional workaround, whereas decoupling risks the occasional impression that Discourse is broken. I strongly prefer the former.
What might be more useful in a later iteration of groups would be Group-to-Group relationships. Then you could have “UX Team” as a group with a child-relationship to “UX Managers”.
I don’t understand the security argument - I agree that there’s no security benefit to it, I’m interested in the feature from a usability/management perspective. Is there some security risk I’m not aware of? Group owners still have to be set by an admin, the only power they have is adding/removing group members, and group membership is entirely an organizational tool.
The only benefits conferred by group membership are either organization-specific (“these are the leaders of x”) or possibly the automatic trust level granted, but none of this is different whether or not the group owner is part of the group or not.
I’m not quite certain what prompted this, but there’s nothing preventing me from creating this setup right now.
I can see where you’re coming from, but what I’d like to emphasize here is the second situation I mentioned in my first post. Here, it doesn’t make sense to think of the group owner as a member of the group, anymore than it would make sense prior to this feature to consider a forum admin part of a group because they were by necessity the owner of all the groups.
e.g.: One of the uses I have in mind is that my forum has a group for newcomers* that needs to be managed. I’m really looking for someone to take the role of “person who moves people into and out of” this group away from me. We have team members who role is specifically to handle working with new people, and so group owner makes perfect sense, but group member not so much.
Additionally, if the public group UX gets more attention, it would end up being swamped by the relatively more active leaders and not show much from our “still getting their sea legs” (so to speak) new folk.
*edit: We have different groups of newcomers is why the automatic system isn’t solely used here, if anyone was curious. One of our uses of the custom groups is to supplement the default hierarchy, which works great as is, better with group owners, and even better if we can preserve current group membership when assigning group owners
Groups are very much a security construct, they confer access to categories.
I am still not following, what is the practical concern of having Sally a TL4 user be owner of newcomers and have membership? The @ expansion thing is going to change, she can suppress notifications if needed, she will not be pushed down to TL1, the UX clearly flags her as owner.
Hm, right, you can assign category access by group. I guess I just don’t understand what’s different, security-wise, switching between: user is assigned group owner role and group membership is then automatically conferred (current) and user is assigned group owner role without conferring group membership.
The practical concerns really just amount to: it’s a bit of a nuisance and requires some change in our normal operation without what seems like, to me, much justification. Much less nuisance than operating before this feature! And ultimately not having this isn’t going to kill us, so we can just move on if you do not already feel compelled to change the setup.
I didn’t mean to go on as long about it as I have here, I just tend to ramble on when I’m trying to explain myself. 
“Group manager” should be a property of the group membership, not the user.
1 Like
This is pretty much done now, you can appoint group managers who can manage a group on the public groups page. Closing
5 Likes
Discussion continued here: