Skip to:
Content

BuddyPress.org

Opened 12 years ago

Closed 12 years ago

#4414 closed enhancement (fixed)

Admin UI for Groups management

Reported by: boonebgorges's profile boonebgorges Owned by: boonebgorges's profile boonebgorges
Milestone: 1.7 Priority: normal
Severity: major Version:
Component: Administration Keywords:
Cc: karmatosed@…, georgemamadashvili@…, vpundir@…

Description

As part of our ongoing project of improved content administration, let's bring Group management into the Dashboard.

Several years ago, I wrote a plugin called BP Group Management, which has most of the features that would probably be required in a first iteration:

  • Ability to see a sortable list of groups, with links to delete, edit, or visit the group
  • For each group, a way to manage members (add, remove, promote, demote, kick/ban)

Should probably have a way to edit the group's Name and Description as well.

Much of the UI can probably be inherited from DJPaul's excellent Activity admin area.

Assigning to myself for the moment, since I wrote the original plugin. I'll try to take a swing at a preliminary patch in the upcoming two weeks.

Attachments (4)

4414.patch (42.8 KB) - added by boonebgorges 12 years ago.
4414.02.patch (55.6 KB) - added by boonebgorges 12 years ago.
suggestion.jpg (151.7 KB) - added by karmatosed 12 years ago.
4414.03.patch (55.5 KB) - added by boonebgorges 12 years ago.

Download all attachments as: .zip

Change History (42)

#1 @boonebgorges
12 years ago

  • Status changed from new to assigned

#2 @boonebgorges
12 years ago

  • Keywords has-patch needs-ui needs-testing dev-feedback added

First pass at the functionality attached. See 4414.patch.

Should be pretty much fully functional. There are a couple of things that aren't done yet, but there's enough there to get some feedback on UI, etc. Known issues:

  • Add new members AJAX. I'm going to add some autocomplete here. For now, you have to manually type a comma-separated list of user_logins.
  • Pagination. I haven't tested with large numbers of group. I assume it'll work since I based it on the Activity component, but it'll need eyeballs.
  • Styling. There are quite a few places where it's on the ugly side. Patches welcome.
  • Help text. Everything there currently is copypasta from the Activity Admin.
  • There may also be other activities copy-paste garbage hanging around

You'll note that I played with the Roles UI a bit. I think the dropdown (as opposed to the links found in the the group admin area proper) is quite nice, but I'm happy to accept suggestions.

If everyone thinks that this is on the right track - I think it's about 75% there - I'll commit it and we can iterate.

@boonebgorges
12 years ago

#3 @DJPaul
12 years ago

I'll give this a try soon. Question: are we adding a is_spam status for Groups, like activity, or should/is that going to be a separate ticket for another point in the future?

#4 @boonebgorges
12 years ago

are we adding a is_spam status for Groups, like activity, or should/is that going to be a separate ticket for another point in the future?

It's not in the patch. If it's going to be added, I think it should probably be done separately, maybe after this ticket is mostly done, because it's going to take some front-end and schema work as well. I'm thinking that it's more than I want to take on in 1.7, unless you think it's a must-have for the Admin screens.

Great job on the Activity admin, btw - this was the first time I'd really gone through it line-by-line.

#5 @DennisSmolek
12 years ago

Out of curiosity before I throw it on my test server is the first part saying as an admin you can add users to any group? That would be a real godsend...

#6 @DJPaul
12 years ago

Just had a quick look at the patch. Nice work.

groups / is_spam

You're right, let's leave that out of scope of this ticket.

In addition to your list of known issues, some more points for consideration. These are just my initial thoughts, they may not be any good:

  • Maybe consider adding a sortable "last updated" column to the Groups index page (if the Activity component is enabled).
  • Maybe consider adding a "number of members" column to the Groups index page. And/or same for Moderator and Admin roles, possibly all grouped together in the same column.
  • Maybe consider adding a "group type" column to the Groups index page. (Public/private/hidden).

On the edit group screen, if the member management is left on the edit group screen as it is now:

  • Make group members draggable between the Admin/Mods/Members/Banned categories using something similar to what is in the patch on #3778. The current dropdown boxes would be removed.
  • If above is implemented, consider adding auto-saving specifically for the member roles via AJAX. If it's draggable, it begins to get conceptually similar to ordering widgets around, and those auto-save.
  • I'm not sure this would scale to groups with hundreds of members.

Or, we could split out the member management from the edit group scheme:

  • We'd adopt the most of the UI from the wp-admin Users management screens.
  • Perhaps using the "on hover" quick links to change the user role.

Finally, we won't any group extension's settings automatically added to this screen. We need a groups settings API for this, so this can be something else to consider adding in a future release.

#7 @boonebgorges
12 years ago

DennisSmolek - Yes, that's one of the main reasons for introducing this feature.

DJPaul - Many thanks for the feedback.

Love your ideas for the index page. The 'number of members' bit is likely to introduce a lot of overhead, but maybe we don't care too much in the Dashboard.

Re member management. I have thought a fair amount about this. A couple thoughts:

  • The current actions in the regular group admin are 'Promote to x', 'Demote to member', 'Kick and Ban', 'Remove'. While I normally like verbs in UI, this has never sat right with me. It seems to me that this interface is far clearer when you select the role from a list of options.
  • Related to this: Bulk actions, as things stand, are all but impossible. The dropdowns I introduced make it a bit easier to manage multiple user changes at a time (though it's still cumbersome).
  • I'd also thought of draggable, but I wanted a noscript option too. If the draggable were implemented, I think the dropdowns could be left for noscript purposes. I'm also not sure how it would scale; I suppose the Manage Members widget needs pagination (it has none right now), but clearly draggable will only work if all members (or at least all 4 user types) are displayed on the same page. Maybe draggable could be disabled if you have more than, eg, 100 members in a group.
  • I'm not sure that very much is gained by moving Member Management to a separate screen from Edit. The purpose for the Dashboard panels is to allow super admins to have a simple way to edit (potentially large numbers of) groups. Doubling the number of screens doesn't serve this purpose. Also, the wp-admin Users screens are not really so great that they're worth emulating in detail, IMO.

Group extensions: Correct. I thought about this. It'd actually be possible to automatically pull the edit_screen() method from the group extension into standalone metaboxes, but this is really asking for trouble in terms of custom styling, scripts, etc. I agree this could be a future enhancement.

I'll work on a second revision of the patch, with some of these considerations in mind, in the next week or so.

#8 @karmatosed
12 years ago

  • Cc karmatosed@… added

#9 @hnla
12 years ago

I'd also thought of draggable, but I wanted a noscript option too

Bearing in mind one always builds without JS first and foremost then layers it on as an enhancement - the noscript tag has really been redundant for quite an age.

#10 @boonebgorges
12 years ago

Bearing in mind one always builds without JS first and foremost then layers it on as an enhancement - the noscript tag has really been redundant for quite an age.

Yes. I didn't literally mean a noscript tag. I meant what you said in the first part of the sentence - need to have an option that works without JS before building draggable as a progressive enhancement.

#11 @boonebgorges
12 years ago

4414.02.patch is another pass at the UI. The following changes have been made:

  • Autocomplete UI added for adding new members to groups. Make sure you have SCRIPT_DEBUG enabled in wp-config.php
  • A few extra columns added to the main screen: # members; last activity; status
  • Added some filter tabs to the group list, so that you can view All | Public | Private | Hidden
  • Cleaned up a bit of styling

Outstanding issues:

  • Sortable columns on the directory page only work in one direction. For instance, Last Activity only sorts DESC. This is a limitation of the 'type' parameter of bp_has_groups(). Fixing this for BP 1.7 is possible, but it's beyond the scope of this patch.
  • Still some styling ugliness
  • Haven't fixed help text
  • Bulk delete is not yet implemented

I'll post some screenshots on bpdevel tomorrow and solicit UX advice. Thanks in advance for your feedback.

#12 @Mamaduka
12 years ago

  • Cc georgemamadashvili@… added

#13 @ubernaut
12 years ago

one feature i think would be really cool is the ability to change the slug/permalink for the group.

#14 @karmatosed
12 years ago

I've had a bit of a play with the format for the group editing screen - just a quick sketch for now but hopefully gets across some ideas I'm thinking. See suggestion.jpg for some ideas but to summarise:

My first thoughts are to:

  • Merge group name and description into one box
  • Make search clearer with box around and add name of action into field rather than text under
  • Add find member (for long lists), use accordion method to make page more compact and easier to negotiate.

As far as the group view for seeing all goes - my only thoughts are how useful the ID's are - I've felt this way for a while about non posts so could be something we're stuck with as a convention. I'd also question the same thing of the group edit view and users - do you need to see their IDs?

Version 0, edited 12 years ago by karmatosed (next)

#15 @boonebgorges
12 years ago

karmatosed - Your suggestions are really great. Thanks so much.

Not sure what to say about the IDs. It's not useful information for 90% of the operations you perform on an everyday basis. But if you ever *do* need a group ID, there is currently no way to do it other than digging into the database. So I think it is a useful, non-harmful piece of info. Plus, it provides the de facto "sort by newest" function, since newest groups are those with higher IDs.

#16 @hnla
12 years ago

For developers, and administrators to an extent, clear reference to 'IDs' is hugely useful, having to dash around different screens trying to discover something like an ID is a pita.

#17 @karmatosed
12 years ago

@hnla : yes IDs are useful I wasn't claiming they weren't more 'how useful in format' but let me explain my thinking. I myself discovered a quirk of my own user behaviour, for posts I don't view the ID on the actual edit page I usually look at the url path. My thinking moved on from there as to how IDs could be done differently. My current thinking would be as hover over somehow.

All that said it's a relatively minor point so until a more robust solution happens a stay.

#18 @dcavins
12 years ago

Another meta box below the settings box that plugin authors could tie into would be a nice addition. Enabling BP Docs or BP Documents for the group, for instance. I'll second Karmatosed's recommendation that having the ID be the primary column is sort of developer-centered, not normal-WP-user centered.

#19 @boonebgorges
12 years ago

dcavins - Thanks for the point about plugin authors. One of the things people have liked about my BP Groups Management plugin is that it can be extended for other plugins. I'll ponder a way to make this work - maybe there'll be an easy way to enhance BP_Groups_Extension to allow plugin authors to place an additional metabox on the Admin page.

#20 @Mamaduka
12 years ago

@boonebgorges

Second patch doesn't apply properly.

#21 @boonebgorges
12 years ago

Mamaduka - Looks like I forgot to format it for svn. Try 4414.03.patch.

#22 @boonebgorges
12 years ago

(In [6267]) First pass at Group Administration Dashboard panels

  • Introduces top-level Groups menu
  • Sortable, filterable list of sitewide groups
  • Single group admin pages
  • Autocomplete for adding users to a group
  • Bulk modification of group member roles

See #4414

#23 @boonebgorges
12 years ago

First pass is in.

Still to do:

  • Bulk delete
  • Pagination for group members. Requires #4482
  • ASC/DESC for sortable columns on Groups view. Requires #4483
  • Some styling
  • Extending BP_Group_Extension so that plugins can add metaboxes to the single group admin panel
  • Add Search to the group members list
  • Help text

Feedback or patches welcome!

#24 @boonebgorges
12 years ago

(In [6280]) Improves Group Deletion process in Dashboard

  • Introduces confirmation screen in place of confirmation alert box, since BP Group deletion is permanent
  • Fixes bulk delete

See #4414

#25 @boonebgorges
12 years ago

(In [6282]) Adds support for BP_Group_Extension plugins to Group Admin Dashboard UI

Introduces admin_screen() and admin_screen_save() methods to BP_Group_Extension
base class, paralleling create_screen() and edit_screen().

See #4414

#26 @boonebgorges
12 years ago

In r6282 I added support for BP_Group_Extension plugins to add their own metaboxes to the Dashboard UI. It works just like create_screen()/create_screen_save() and edit_screen()/edit_screen_save(). I'll write something up for the codex and bpdevel, but here is a minimal plugin to give you the idea:

class Test_4414 extends BP_Group_Extension {
	function __construct() {
		$this->name = '4414';
		$this->slug = 'test-4414';
                $this->enable_admin_item = true;
	}

	function admin_screen( $group_id ) {
		$meta_value = groups_get_groupmeta( $group_id, 'test_4414_meta' );
		?>
		<input type="text" name="test-field" value="<?php echo esc_attr( $meta_value ) ?>" />
		<?php
	}

	function admin_screen_save( $group_id ) {
		$meta_value = isset( $_POST['test-field'] ) ? $_POST['test-field'] : '';
		groups_update_groupmeta( $group_id, 'test_4414_meta', $meta_value );
	}
}
bp_register_group_extension( 'Test_4414' );

#27 follow-up: @DJPaul
12 years ago

Only concern I have is that it defaults the meta box to "normal" and "core" positions. You couldn't register it on the side by default.

#28 in reply to: ↑ 27 @boonebgorges
12 years ago

Replying to DJPaul:

Only concern I have is that it defaults the meta box to "normal" and "core" positions. You couldn't register it on the side by default.

Good call. I'll add a way to make this customizable.

#29 @androliyah
12 years ago

How do I add the patch? Manually copy-paste the contents into my installation?

#30 @hnla
12 years ago

Mamaduka - Looks like I forgot to format it for svn. Try 4414.03.patch.

They still run SVN here Boone, I know it's rubbish and git is lurvely but...

SVN patches would be cool :)

#31 @boonebgorges
12 years ago

How do I add the patch? Manually copy-paste the contents into my installation?

The patch has already been added to BP trunk, primarily in r6267. If you're running trunk, just svn up. If you're running a release version of BuddyPress (such as 1.6.1), I would recommend installing trunk from svn in a development enviroment for the moment, as trunk is not production-ready at the moment, and there is no easy way to apply the changes to 1.6.1.

SVN patches would be cool :)

The only relevant difference between a Git-formatted patch and an SVN-formatted patch is that Git puts pseudo-branch prefixes on the file paths. I usually work around this by running git diff --no-prefix. But even when I forget, you can still apply using patch -p1 instead of patch -p0.

#32 @DJPaul
12 years ago

  • Keywords needs-patch added; has-patch needs-testing dev-feedback removed

#34 @johnjamesjacoby
12 years ago

  • Keywords reporter-feedback added; needs-ui needs-patch removed

Boone - Any updates here?

#35 @boonebgorges
12 years ago

(In [6642]) Allow BP_Group_Extension plugins to specify admin metabox priority and context

See #4414

#36 @boonebgorges
12 years ago

(In [6643]) Only register BP_Group_Extension meta box if the display callback is defined. See #4414

#37 @boonebgorges
12 years ago

(In [6644]) Replaces copypasta from Activity admin in Group admin contextual help tabs.

See #4414

#38 @boonebgorges
12 years ago

  • Keywords reporter-feedback removed
  • Resolution set to fixed
  • Status changed from assigned to closed

I did some cleanup and things are looking pretty good for this feature.

I've added documentation on the new BP_Group_Extension methods to http://codex.buddypress.org/developer/plugin-development/group-extension-api/. Please edit as you see fit.

Closing this ticket as Resolved. For further feature requests and bug reports, please open separate tickets. Thanks.

Note: See TracTickets for help on using tickets.