Improved Group Members Management

@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 :wink:

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. :smile:

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 :smile:
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. :slight_smile:

ā€œ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: