Replacing the “primary group” feature with the select2-autosuggest for existing groups. I am still unsure about whether or not show the trust groups here, too (as they are not actually editable). And move the primary selection as a two-click select over the pre-selected groups in the into the controls area:
The idea is to separate the save-button from the user-management. I’d suggest splitting the screen into half, making the top part about the group settings and the second half the list of the users – working as an endless-scrolling list similar to the admin-user-list. Like this:
Not crazy about point #2 or separating the group editing from member management.
So the advanced filtering seems to be overkill and will lead to other issues.
I like sections #1 and #3 though.
I like the quick-add and quick-remove actions on the member list (but again, that wouldn’t work so well if you were really listing users based on some combinatorial search).
Best to keep the member list as part of what is shown on the group page, IMHO.
Keep the save button up top and tied only to editing the group properties, as you suggested.
Editing the member list with quick-add or quick-remove would be immediate (if an immediate quick remove is too dangerous, maybe itd be better to make those check boxes with a separate remove button that has a confirmation modal)
Current UI is fine for small groups, so instead of stripping it completely
Make the control read only if there are more than say 50 members in the group.
Add a “see full list” link at the bottom that takes you to the listview ui.
Not a fan of “in:Admins” widget thing. Instead:
Active Users -> Group name in the header. less magic and simpler.
We need to ensure that the “remove” and “add” buttons are only there when the user list is scoped to a group.
Definitely show all groups including trust groups on the user page. For automatic groups there should be no “x” to remove. (no x on admins or trust_level_1 etc…)
Can you amend the spec and I will do a second pass?
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.
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.
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)
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.
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)
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.
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 http://www.discourse.org/buy if you wish to speed things along
@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?
