[wp-hackers] Get All Users with Specific capability

[Ryan Bilesky]

Iif you are doing that chances are you would probably just use a plugin that
will let you manage capabilities directly though it can be possible perhaps
for a plugin to introduce its own custom caps or for a new core cap.

There are really two options, option one is you could determain the current
role by caps, ie if they can manage_options you know they are an admin, if
not check a cap first avalible at the next level, or introduce a role
specific cap (bring back levels for instance).

The other thing is to still store the role in user meta, this way you can
still display in the admin panel the specific role for a given user like
today.

On Feb 16, 2011 7:17 AM, "Peter van der Meij" <peter at pjvdm.nl> wrote:
> but if you would want to add a capability to a role, you don't know
> which user has which role.
> so you would have to do this for every user.
>
>
> Kind regards,
>
> Peter van der Meij
> e: peter at pjvdm.nl
> M: +316 302 716 98
>
>
> On 16-2-2011 14:02, Ryan Bilesky wrote:
>> Interesting, but hakre's comment got me thinking...what if instead of
doing
>> away with user specific capabilities, we did away with roles. I mean
since
>> when does it make sense to link a user to an arbitrary grouping (ie role)
>> that just links to the actual capabilities. Best I can tell this was done
>> for simplicity, most average user's want to make a user an editor, not
make
>> a user who has capabilities a, b, c, 1, 2, 3, x, y, and z if you know
what I
>> mean. That is all fine and good and I can understand that. But who says
>> you have to link the user to a role. Picture this, you add a new table
>> let's call it usercaps (yes, you could use usermeta for this but it'll
>> probably be cleaner to do this is a different table) that will link users
to
>> caps, with an arbitrary auto incremented number to act as primary key,
the
>> scheme would be like this:
>>
>> | ID (pk) | User ID | Capability |
>> --------------------------------------
>> | 1 | 1 | manage_options
>>
>> ect...this can be done either way, select * from usercaps where User ID =
1
>> and Capability = manage_options to see if the user has the cap, select
>> UserID from usercaps where Capability = manage_options to see who has
>> manage_options, or select Capability from usercaps where User ID = 1 to
see
>> what caps user 1 has.
>>
>> Now what about the general user, we want to keep simple things simple
while
>> remaining flexible is the key, you we will still have something called
>> roles, it will be much like a template of capabilities to give the user,
the
>> net effect cleanner in the db, keeps the simple role system for the
general
>> user, but it's flexible for those power users.
>>
>> Now for the power users, there would be an API that a plugin could
utilize
>> to replace the role selector with a direct capability selector so now
each
>> user can have their own distinct set of capabilities, if needed. This
would
>> be done via Plugin API with a plugin only for those requiring something
more
>> flexible than just the basic roles.
>>
>> This way you change out your old V6 roles/capabilities engine with a more
>> powerful v8, while keeping things simple for the average user but
remaining
>> flexible for advanced users giving them more power if they need it (hey
>> that's a good analogy, I'll have to remember that one, lol).
>>
>> So the big question...any feedback, suggestions, complaints, death
threats
>> about this? I am interested in hearing what you all have to say.
>>
>> On Tue, Feb 15, 2011 at 8:18 PM, Andrew Nacin<wp at andrewnacin.com> wrote:
>>
>>> On Tue, Feb 15, 2011 at 7:48 PM, Jeremy Clarke<jer at simianuprising.com
>>>> wrote:
>>>> In 3.1 you can use get_users('role=subscriber') to avoid using any
custom
>>>> SQL but like you say that is not usually good enough and capabilities
are
>>>> fundamentally more useful and important in WP (especially in public
>>> plugins
>>>> where you can't make any assumptions about roles).
>>>>
>>>> IMHO get_users() should be able to take in a capability as well as
roles,
>>>> too bad that wasn't included in 3.1. It's certainly a complicated
>>> problem,
>>>> but it doesn't seem impossible, just potentially irresponsible WRT
server
>>>> performance (you'd want to cache it if you use it on most pageloads).
>>>
>>> The solution here is to move away from a schema where users are given
>>> capabilities directly.
>>>
>>> Currently dormant Trac ticket:
http://core.trac.wordpress.org/ticket/10201
>>>
>>> While we're not sure when it'll be implemented, most of us are inclined
to
>>> implement the proposal outlined in detail here:
>>>
>>>
http://andrewnacin.com/2010/04/03/overhauling-roles-and-capabilities-part-2/
>>>
>>> Cheers,
>>> Nacin
>>> _______________________________________________
>>> wp-hackers mailing list
>>> wp-hackers at lists.automattic.com
>>> http://lists.automattic.com/mailman/listinfo/wp-hackers
>>>
>> _______________________________________________
>> wp-hackers mailing list
>> wp-hackers at lists.automattic.com
>> http://lists.automattic.com/mailman/listinfo/wp-hackers
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers