[buddypress-trac] [BuddyPress Trac] #6175: "Profile Fields" admin page requires 'manage_options' capability

buddypress-trac noreply at wordpress.org
Fri Jan 30 19:34:11 UTC 2015


#6175: "Profile Fields" admin page requires 'manage_options' capability
------------------------------+-------------------------------------
 Reporter:  johnjamesjacoby   |      Owner:
     Type:  defect (bug)      |     Status:  new
 Priority:  normal            |  Milestone:  2.3
Component:  Roles/Capability  |    Version:  1.6
 Severity:  normal            |   Keywords:  needs-patch 2nd-opinion
------------------------------+-------------------------------------
 For a user to see and access the "Profile Fields" admin page, we first
 check `bp_moderate` via a call to `bp_current_user_can()` which checks
 their capability from the root blog of the installation, and immediately
 return if they are not capable.

 Next, however, we call `add_users_page()` and pass `manage_options`
 through as the capability to check. For single site installations, this is
 fine, but multi-blog and/or multisite may run into a conflict where a user
 can `bp_moderate` but cannot `manage_options`.

 Assuming for a moment that `bp_moderate` is our "super moderator" catch-
 all capability, their relation to `manage_options` shouldn't matter. A
 similar issue arrises in `BP_Members_List_Table::no_items()` where we
 check for `manage_network_users` if multisite, but fallback to
 `manage_options` with no designation about single/multi/site/blog
 installations.

 Barring introducing an entire role and capability feature-set, I think we
 need to audit and test our `manage_options` usages to ensure they're
 providing (and blocking) the access we expect for them to.

--
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/6175>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac


More information about the buddypress-trac mailing list