[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