[wp-hackers] Capabilities as a taxonomy

Moya, Eddie emoya at tribune.com
Fri Jan 22 20:12:36 UTC 2010

That makes some sense. I think if wordpress moved toward having more
granulized capabilities (e.g. Different caps for widgets/themes, or further
still, different caps for items/areas within a page), which it really should
do, then a system where you treat caps like a taxonomy starts to make a lot
of sense. 

However with regard to assigning multiple roles to a single user, Im not
sure if I completely understand why that is necessary. It seems to me this
would create complications in a large system. It could potentially lead to
lots of unique sets of users with no single way to describe them.

For example, if you had a separate editors (e), writers (w), comment
moderators (cm), etc,.. You might have a bunch of users who are (e + w), and
then one or two who are w + cm and some who are e + w + cm.

While this doesn't seem all that problematic in the small scale, once you
consider that a large site using wpmu might have thousands of users, on
hundreds of blogs, with a good number of custom caps for plugins - it can be
a user permissions nightmare. You could have no simple way to address the
group of users who are (e + w), which is not so great if you want to make a
change to their editing capabilities but preserve those of someone who is
just and editor, or who is an (e + w + cm). Additionally, as much as we
don't like to think of roles as hierarchical, in some cases, they need to be
just that - and the lack of structure would make that all the more

Seems that you could alternatively just create a new role for those
instances where you would want to combine the caps. I realize that at some
level its just good to give developers as much flexibility as possible so I
don't know that it should be removed since its already there, but from an
objective standpoint, if it weren't there, I wouldn't see the case for
putting it in.

I think the problem of performance is one that should be primarily addressed
in terms of restructuring the way roles and capabilities are implemented
though, not just chopping off functionality.

All that said, the taxonomic take on capabilities is still interesting.

Eddie Moya
Tribune Interactive
Applications Developer

On 1/22/10 10:48 AM, "Otto" <otto at ottodestruct.com> wrote:

> On Fri, Jan 22, 2010 at 10:23 AM, Andrew Nacin <wp at andrewnacin.com> wrote:
>> Actually, that still exists.
>> The current system allows for a single user to have multiple roles and
>> overriding individual capabilities as well. What has been proposed is
>> limiting users to a single role with no opportunity for individual
>> capabilities on top of that.
> I'm okay with eliminating individual capabilities, but we really
> should keep multi-role. I can envision a system where you separate
> "writers" from "editors" and have a role just for "comment moderators"
> and so forth. It would make more sense to assign one user to multiple
> roles than to make combined roles just for them.
> If performance is a problem, then we need to look at redesigning to
> make it not a problem. However I don't think that means we should give
> up the more obvious and useful configuration abilities.
> The most common case is probably going to be "does user A have
> capability X?". So optimize for that and other common query cases.
> It's unlikely we'll need a system that can also do "what users have
> capability X?", because that's not something you would normally care
> about. You'd be more likely to ask "what are the roles all the users
> are in?" and similar.
> Define your use cases, optimize the design for those.
> The main cases I see are:
> "does user A have capability X?"
> "what roles does user A have?"
> "what capabilities does role R have?"
> Given this, I'd probably make the roles into usermeta fields (_role?),
> and make the capabilities into terms in a taxonomy, linking them to
> role names. User has role AAA, and a taxonomy exists with AAA or
> something as the name of it. Terms like "can_edit_posts" and similar
> are related to that role.
> Pulling a user's roles is then a simple meta lookup. Pulling all terms
> for a taxonomy is one select, joining the terms to the relationships
> and taxonomy (same as tags/categories). Checking a single capability
> on a user is a combination of the two. If role names match taxonomy
> names, that's a single select as well (albeit with a lot of joining).
> Might want to make role names be forced to have a hidden prefix or
> something to make this unlikely to interfere with other custom
> taxonomies.
> If you want to reverse the process, it's a bit more difficult, but not
> crazily so. "What users have capability X?" would be a) Find the term
> for that capability, joined to relationships to see which taxonomies
> it's in. This gives you the role names. Then b) select the usermeta
> where _role in roles to get the list of user ids.
> -Otto
> Sent from Memphis, TN, United States
> _______________________________________________
> 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