Admin panels meta cap review for Group and Activity moderation

[ericlewis]

The Activity and Groups admin menus are created with similar logic, here's the Groups for example:

if ( ! bp_current_user_can( 'bp_moderate' ) )
	return;

// Add our screen
$hook = add_menu_page(
	__( 'Groups', 'buddypress' ),
	__( 'Groups', 'buddypress' ),
	'manage_options',
	'bp-groups',
	'bp_groups_admin',
	'div'
);

This reads strange to me - we check if the user can 'bp_moderate', and then give add_menu_page the capability 'manage_options'. We should probably use the same capability 'bp_moderate in the add_menu_page call, in case an administrator might want to give a user the ability to moderate Activity and Groups, but not need to give them 'manage_options'.

[ericlewis]

replace manage_options with bp_moderate in add_menu_page calls

[johnjamesjacoby]

Most of the 'bp_moderate' checks were previously is_super_admin() checks. We never got around to building out capabilities the way we did in bbPress last year, so this is a relic of that.

Thanks for the patch! Moving to 1.9.

[boonebgorges]

Yup, good catch. In fact, with the cap changed in add_menu_page(), we no longer need the inital current_user_can() check - add_menu_page() takes care of it for access to the panel, and the load-$hook action will never fire for unauthorized users.

[boonebgorges]

In 7312:

Use bp_moderate cap for Activity and Groups panels

When adding the Activity and Groups administration panels using
add_menu_page(), use the 'bp_moderate' cap rather than 'manage_options'
(which was itself a stand-in for our old is_super_admin() checks).
This allows access to the panels to be granted to non-super-admin users
via plugin. The change also means that we can remove the redundant
current_user_can() check at the beginning of the methods in question.

Fixes #5115

Props ericlewis