Improved Group Members Management

I think so. For the explicit remove button I added here, I’d say there should be a confirm-popup. For the implicit widget we have atm, this would have been awful though.

Also bring in the wrench icon for bulk operations. Same concept as working with multiple posts in a topic. Use case: imaginary community has a staff group of 15 people and has decided that 5 of them should become members of imaginary specialist group. They want to do that in effectively one move, not five.


I think this is out of scope for v1 of this spec. I take your use case for the reason:

Currently we bind the Members-UI-Part to the specific group only. So the only action per item is “remove” and thus the only thing to put a multi-select on. And though I see that you might have to remove say, 4 people from the list, this isn’t too often the case. Because of the limited scope the UI part is in though, it wouldn’t make much sense if from the wrench you could add the people to a different group.

And though I see your point of wanting to add multiple people easily, I think the autosuggest (and on-enter) that is in the members area is much easier. You just type the five people there for the new group – not too hard.

In the current spec, I am not altering the normal user-lists though I see how this would make a hell lot of sense in a second step to allow quicker membership assignments.

@sam, did you have time to take a look at the spec? What do you think? I could see if I can get moving on this tomorrow or over the weekend.

Let’s scope this down a bit.

Keep the current UI as is, only change if there are more than 50 members the group members UI becomes readonly.

I think it makes more sense to keep the UI for adding and removing users for large groups under


This way we look at different orders later on. search for a user in a group. and reuse the existing UI.

For example, the new UI will not allow you to easily search by email for a user in a group, will not show all the stats and so on.

If you want to get started, I say get started on #1, totally fine with those changes to the admin/user page. Please account for groups that you can not remove (like trust level and so on, don’t show an x on them)

Holy cow, that was more work than expected (select2 is nasty.) but I made it:

Including the locking of automatic groups.


Reviving this feature conversation.

Group administration is troublesome when the group is large. The
client currently sends the entire updated membership list to the
server whenever there are any changes, and the server has to figure
out what has changed.

I propose:

  • paginated viewing for group membership
  • incremental adds and deletes for group membership

This is to set the stage for a new “group owner” role that can be
designated on a per-group basis.

A group owner should be able to add and remove members from any group
over which they have ownership.

Group owner should not be able to change:

  • group name
  • visibility setting
  • alias levels

These functions should remain restricted to administrators.

I suggest that the existing public group membership page
(/groups/{group-name}/members) be extended for this purpose. The
existing group admin page (under /admin/groups) will remain
available only to staff.

First step is to update the group membership UI, but restrict the
editing features to staff. Once the UI is settled, add the group owner


We are fine with this, curious to see some UI mockups. API changes are pretty straight forward.

Planning to do something similar to what @lightyear suggested in #2 in his topic post, except moving it to the /groups/xxx/members page. For large groups I want to use the same magic scrolling as Discourse does for posts. First I need to learn Ember.



That is a good place for the page, its going to need a filter box as well. delete should use the same UI pattern as used elsewhere on the front end (the bin icon to the right)


Yes, filtering is on my list. Took me a while to figure out the user-selector component, I hope there’s already something I can use for filtering.

I want to replace the links to user pages with the pop-up user cards just like on the topic list pages. Not sure how to do that - there seems to a necessary data-user-card attribute but there must be more to it than that.

1 Like

Has there been any progress on group ownership? I’d really love this feature (a lot of others as well I could imagine) and there are barely alternatives (making far too many people admins or excessive effort for those who are).

As with many other features, it depends how many paying customers are asking for it, see if you wish to speed things along :wink:

@Wowl The back end is all in place for group managers. UI side is still pending, because my Ember skills are weak and I haven’t spent much time on this. Can you help?


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


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.


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.