[wp-hackers] Get All Users with Specific capability

Ryan Bilesky rbilesky at gmail.com
Wed Feb 16 13:02:11 UTC 2011


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
>


More information about the wp-hackers mailing list