[wp-hackers] What does user_can really check?

[Dion Hulse (dd32)]

On 24 November 2011 05:15, Kevin Newman <CaptainN at unfocus.com> wrote:
> Anyway, all I really need to know is, if I take a subscriber (as a shorthand
> for checking the user has ONLY "read" cap), and give them an additional cap,
> will that change their role to something other than subscriber, or does the
> role have to be specifically changed? That's the question.

If you give the "subscriber" role EVERY capability possible, they will
still be a Subscriber, and current_user_can('subscriber') will return
true.
If you remove every capability from the Administrator role,
current_user_can('administrator') will return true, however,
current_user_can('publish_posts'); would return false.
The only way to "know" is 1 user role is "greater than" another user
role, is to compare that one has a subset of the others capabilities -
and even then, that's not really possible either in some cases.

So: Roles are NOT hierarchical. They have no order to them, other than
human's opinion of "importance". This is why you check for a given
Capability when processing a request, rather than what role they're
in.
If you want to "trim the fat" and only care about users that can add
posts, you might want to do !user_can($id, 'edit_posts'); or
something.. Something that identifies the capability that you deem
"important"

> To make this clearer in the API, I would suggest a user_is method be added
> to core, as a way to check for a specific role, rather than overloading the
> user_can method (incorrectly) the way it is now. Incorrectly because
> "user_can" - "do what subscriber can do" - it should return true for admins,
> contribs, etc. when you check for "subscriber" caps - but now it returns
> false.

Except you're not asking "do what a subscriber can" because it has no
knowledge of what you actually want to do.. tell it the action that
you're querying for and it'll tell you straight away the correct
response.
It responding to the role name is just a legacy thing, something that
can't be removed - because people use it unfortunately, same as the
user_levels, that should've gone a long time ago.. but I still correct
examples people put into the codex that use it..