[wp-hackers] User Capabilities

[Ryan Boren]

> 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.)

Roght you are.

> 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.

Indeed.  It's not quite there.

> 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.

I'll give it a try when I get home.

> 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.

That's the intention, altough the implementation doesn't correctly check
for this at the moment.  The idea is if the cap is not set in the user's
cap list, then fall through to role checking.  If it is set and false,
then the user does not have that cap and the role should not be checked.

> 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.

Matt added the prefix thing to the user level when he added the usermeta
table.  I extended it to the roles and caps.  I think the idea is to make
it possible share the user and usermeta tables but be able to partition
privileges.

Ryan