Skip to:

Opened 9 years ago

Last modified 8 years ago

#6175 new defect (bug)

"Profile Fields" admin page requires 'manage_options' capability

Reported by: johnjamesjacoby's profile johnjamesjacoby Owned by:
Milestone: Awaiting Contributions Priority: normal
Severity: normal Version: 1.6
Component: Core 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.

Change History (3)

#1 @r-a-y
9 years ago

Related: #4991.

#2 @DJPaul
9 years ago

  • Milestone changed from 2.3 to Future Release

#3 @DJPaul
8 years ago

  • Component changed from API - Roles/Capability to Core
Note: See TracTickets for help on using tickets.