#14066 closed defect (bug) (fixed)
has_cap() bug when logged in as super-admin
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | 3.0.1 | Priority: | normal |
Severity: | major | Version: | 3.0 |
Component: | Role/Capability | Keywords: | has-patch capabilities, user, permissions |
Focuses: | Cc: |
Description
I've working with a site that has a plugin that adds custom capabilities. When logged in as a super-admin, on the user edit screen (editing a subscriber, not my own profile) all the capabilities were checked.
The plugin (Role Manager) properly grabs the currently-edited user object and calls the has_cap() method on it to see if the user has the current capability.
During the has_cap() check WordPress does the following:
if ( is_multisite() && is_super_admin() ) { if ( in_array('do_not_allow', $caps) ) return false; return true; }
The is_super_admin() function defaults to the logged-in user if no user ID is passed. Since has_cap() isn't passing the current object's user ID (i.e., $this->ID) it's checking my super-user's capabilities and returning a false positive.
I suggest we pass the current object's user ID into the is_super_admin() method in this instance, so that it's properly checking the object's capabilities instead of falling back to the currently logged in user.
if ( is_multisite() && is_super_admin($this->ID) ) { if ( in_array('do_not_allow', $caps) ) return false; return true; }
Patch is attached.
(In [15311]) Pass ID to is_super_admin(). Props bigdawggi. fixes #14066 for 3.1