[buddypress-trac] [BuddyPress Trac] #5197: Access Member Profiles from the Admin Backend

[buddypress-trac]

#5197: Access Member Profiles from the Admin Backend
-------------------------+-----------------------------
 Reporter:  svenl77      |       Owner:
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Future Release
Component:  Members      |     Version:
 Severity:  normal       |  Resolution:
 Keywords:  needs-patch  |
-------------------------+-----------------------------

Comment (by imath):

 Following up on this ticket, I've built a patch (5197.diff) I wish to have
 your opinion on. I may have extended the scope of the ticket.

 In my latest comment, I've described four options, this patch introduces
 some improvement on option 4 :
 - each group of profiles has his own metabox
 - the metabox showing the avatar includes a link to delete the avatar, in
 case the administrator need to moderate a non appropriate avatar for the
 audience he targets.

 This patch will add his main code into bp-xprofile-admin.php, it includes
 some new css rules in /bp-xprofile/admin/css/admin.css to style the
 profile navigation to "toggle" between community profile/ WordPress
 profile. I've tested it and most things seems to work fine.

 I haven't included the visisbility settings and "clear" selected options
 features, as it will require to load some extra javascript.

 This a screen capture of
 [http://www.flickr.com/photos/im4th/12121075125/sizes/o/in/photostream/
 this Profile page]

 Some thoughts :
 1/ As, I've added some functions not related to xprofile, I really think
 this code should be best located in new files in the members component :
 - php part /bp-members/bp-members-admin.php
 - js and css /bp-members/admin/css and /bp-members/admin/js

 This way in case the xprofile component is not active some actions could
 still be available. And the new file bp-members-admin.php can host other
 functions in order to list pending registrations for example.

 2/ It will surely need to make sure the spam/unspam process is ok
 For instance it works fine on single site, but on multisite, if spaming
 from the profile page, then unspaming from the WordPress users.php page,
 the user is unspamed for WordPress but not for BuddyPress. see #5275
 Having this feature can help to help Administrators to spam/unspam user in
 a non multisite config see #5113

 3/ I had to set the buddypress()->displayed_user datas as some xprofile
 template functions do not have a user_id argument and use
 bp_displayed_user_id() in their code.

 4/ Having this kind of UI can be interesting if one day, a function like
 bp_is_active_for_user() or bp_current_user_can( 'component' ) is added.
 Administrators would be able to manage a user's capacities from there.

--
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/5197#comment:10>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac