[wp-hackers] User Capabilities
Owen Winkler
ringmaster at midnightcircus.com
Fri Jul 8 15:10:33 GMT 2005
Ryan Boren wrote:
> Sounds good. Patch attached.
Holy caps, Batman.
There's a glitch or two. I don't think that usermeta values get
unserialized in get_userdata() when they are added to the WP_User
object, so checking against $this->caps[] in WP_User::has_cap() won't
return a valid value. (It was returning "a" for me, which is "true",
even though I shouldn't have the cap I requested.)
The confusing IF statement in that function seems to say:
If ((the user does not have the cap directly) and (a role exists with
that name) and (the role doesn't have the cap)) then the user doesn't
have the cap.
A problem is that it's not checking the requested cap against the caps
of the *user's* roles. It's only checking the requested cap against the
caps of a role with the same name as the requested cap, which is
incorrect.
I've attached new files to try with changes that look to me like they
work. It builds a complete list of caps when WP_User is created by
reading the user roles recursively. Apply my patch over Ryan's and
replace the capabilities.php file with this new one. You'll need to
delete the options table row that contains the roles and run the upgrade
to see the recursive roles work.
Hint: echo $current_user->caps from admin-footer.php.
Can you set a cap to false to deny that cap? I think that my patch
could enable this. Just a thought, since it might be useful to grant
users capabilities by role, and then revoke a single permission.
As I said before, the admin UI need not support setting these
capabilities, but it's handy if the core supports them if someone wants
to augment the permission page by plugin.
I also see in this code a trend toward assigning permissions to
different table prefixes, which implies that MU functionality is in the
pipeline for the core. I'm not up to speed on MU - Which tables are
shared and which aren't? It seems that the options table would be a
shared table, and that any option that's not global should have a table
prefix. This would be good to know for plugins with option data that
want to support MU.
Owen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: newcaps.diff
Type: text/x-patch
Size: 5100 bytes
Desc: not available
Url : http://comox.textdrive.com/pipermail/wp-hackers/attachments/20050708/3c7be53f/newcaps.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: capabilities.php
Type: application/x-php
Size: 5469 bytes
Desc: not available
Url : http://comox.textdrive.com/pipermail/wp-hackers/attachments/20050708/3c7be53f/capabilities.bin
More information about the wp-hackers
mailing list