Improved Group Members Management

spec
rfc
(Benjamin Kampmann) #4

I disagree. things like the weird behaviour of the back-button and no undo make this widget very error-prone in our daily work (aka accidentally deleting people without even noticing). I’d separate the concern of group settings from the member management.

I see the point of that being hidden and changing the user view making it complex though. So I amended the Spec to include a simplified user-list on the bottom of the group instead of the current widget and make the top part only about the settings. This version would not amend the User-Listing-View (because of previously mentioned complexity problems) and of course you can’t remove or add on automatic lists. But I think it is much cleaner and easier to follow – and through endless-scrolling shouldn’t be limited to anything ever.

1 Like
(Dave McClure) #5

I like the new spec.

Regarding this:

Should there be a confirmation when removing a user from a group?

2 Likes
(Benjamin Kampmann) #6

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.

(Daniel Ritchie) #7

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.

3 Likes
(Benjamin Kampmann) #8

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.

(Sam Saffron) #9

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

/admin/users/list/active?group_id=99

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)

Category-Specific Moderators, phase 1 RFC
(Benjamin Kampmann) #10

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

Including the locking of automatic groups.

3 Likes
(Jason May) #11

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
role.

6 Likes
Allow moderators to add a member to a group?
(Sam Saffron) #12

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

(Jason May) #13

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.

2 Likes
(Jason May) #14

8 Likes
(Sam Saffron) #15

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)

2 Likes
(Jason May) #16

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.

(Jason May) #17

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
#18

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).

(Jeff Atwood) #19

As with many other features, it depends how many paying customers are asking for it, see http://www.discourse.org/buy if you wish to speed things along :wink:

(Jason May) #20

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

3 Likes
#21

@jmay That is great news! Unfortunately I not only have no Ember skills,
but my HTML, CSS & JS are weak as well. :{

(Jeff Atwood) #22

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
(Sam) #23

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