New Way Of Doing User Roles And Capabilities

[Jeffro]

During the developers chat on Wednesday July 22nd there was a discussion centered around the idea that has already been ok'ed by Matt and Ryan regarding a new way to handle roles and capabilities. I don't understand the jargon in the discussion but I'm hoping that by posting it here, one of you can explain to me the benefits of what they're likely to do. The discussion is posted in ascending order:

MarkJaquith
Here is the basic idea, which has been +1'd by Matt and Ryan (and some others, I think)

Jul 22 21:31:51 2009
MarkJaquith
Drop multiple roles per user. It's not supported in the WP core UI, and almost no one uses it.

Jul 22 21:31:57 2009
hakre
#10201

Jul 22 21:31:58 2009
wp-trac-bot
hakre: http://core.trac.wordpress.org/ticket/10201 normal, normal, 2.9, Denis-de-Bernardy->, assigned, Switch roles to use single role, and no user-specific caps

Jul 22 21:32:04 2009
MarkJaquith
Drop capability negation. Almost no one is using it.

Jul 22 21:32:23 2009
MarkJaquith
Drop adding capabilities to a user directly. Almost no one is using it.

Jul 22 21:32:39 2009
MarkJaquith
The new, simplified model would be: Roles are buckets of capabilities. Users can have one role.

Jul 22 21:32:49 2009
MarkJaquith
Want to tweak someone's capabilities? Add a new role with the desired set.

Jul 22 21:32:52 2009
hakre
what are "Meta Capabilities" and what are "Primitive Capabilities" ??

Jul 22 21:32:54 2009
ddebernardy
all +1 to this, even if it breaks a couple of plugins

Jul 22 21:33:04 2009
hakre
+1 for having a change

Jul 22 21:33:10 2009
ddebernardy
as matt put it, the plugins that are affected are closed source, so no big deal

Jul 22 21:33:12 2009
hakre
-1 for mixing data and modell

Jul 22 21:33:13 2009
MarkJaquith
It'll likely be minor breakage, except for hardcore caps plugins

Jul 22 21:33:33 2009
hakre
+1 for having a getter on telling wether or not multiple roles per user are supported

Jul 22 21:33:56 2009
hakre
i want that optional so this conforms to all the major RBAC shemes

Jul 22 21:34:03 2009
MarkJaquith
It'll simplify our code, and enable us to break past some nasty scaling walls, like the drop down author list, and the users page (which starts to go to crap after 20k or 30k users)

Jul 22 21:34:36 2009
MarkJaquith
Instead of being a serialized blob, it'll just be an ID or a simple text "admin" / "editor" etc

Jul 22 21:34:46 2009
ddebernardy
nod

Jul 22 21:34:55 2009
MarkJaquith
Will enable role => user and cap => role => user lookups.

Jul 22 21:35:04 2009
hakre
+1 for full abstraction of the store layer.

Jul 22 21:35:07 2009
MarkJaquith
i.e. "who is able to ______ ?"

Jul 22 21:35:21 2009
scribu
User Joined

Jul 22 21:35:28 2009
jorbin
I'm guessing there would be no change to current_user_can with this?

Jul 22 21:35:37 2009
MarkJaquith
Upgrade plan for people with custom caps assigned to users: generate a new role at WP upgrade time, put that user in that role. No gaps.

Jul 22 21:35:40 2009
MarkJaquith
jorbin: correct.

Jul 22 21:35:56 2009
ddebernardy
jorbin: current_user_can would not be affected, unless you're using the likes of WP Wishlist

Jul 22 21:36:12 2009
MarkJaquith
So, look at each user's unique cap set, see if a role fits that. If not, generate it on the fly and assign.

Jul 22 21:36:22 2009
hakre
i'm not shure with that. what about the different type of capabilities currently in the code and docs?

Jul 22 21:36:27 2009
hakre
I asked on wp-hackers, no answer

Jul 22 21:36:34 2009
hakre
I asked here, no answer

Jul 22 21:36:35 2009
MarkJaquith
With these simplifications, I'd strongly consider putting basic role management into core.

Jul 22 21:36:42 2009
MarkJaquith
hakre: what's the question?

Jul 22 21:36:51 2009
hakre
what are "Meta Capabilities" and what are "Primitive Capabilities" ??

Jul 22 21:37:15 2009
MarkJaquith
current_user_can( 'edit_post', 1234 ) maybe?

Jul 22 21:37:27 2009
scribu
meta capabilities are tose that take an argument like an id

Jul 22 21:37:31 2009
MarkJaquith
Ones that aren't yes/no but change depending on the parameter

Jul 22 21:37:41 2009
DD32
hakre: Meta is the dynamic ones (ie. edit post), Primitive are the ones w hich are a simple yes/no

Jul 22 21:38:07 2009
MarkJaquith
So are there any major flags for anyone? Anything that would make this a dealbreaker?

Jul 22 21:38:14 2009
jorbin
I sounds like each 'role' (such as admin, editor, etc...) would be a collection of capabilities. New Roles could be easily created and each user would have one role.

Jul 22 21:38:22 2009
jorbin
If that's the case, +1 from me

Jul 22 21:38:22 2009
ddebernardy
MarkJaquith: all +1 over here

Jul 22 21:38:25 2009
MarkJaquith
jorbin: yes.

Jul 22 21:38:39 2009
hakre
edit post is dynamic? there is no primitive like "edit own posts"?

Jul 22 21:38:39 2009
ddebernardy
will write the patch by the end of the month if we're good on the idea

Jul 22 21:38:42 2009
MarkJaquith
ddebernardy: I'll mark this day in my calendar. :-)

Jul 22 21:38:54 2009
MarkJaquith
hakre: there is, but for checking, you pass in the post ID

Jul 22 21:38:55 2009
ppk
+1 for role management into core

Jul 22 21:39:08 2009
hakre
+1 for RBAC

Jul 22 21:39:18 2009
hanni_
User Joined

Jul 22 21:39:35 2009
MarkJaquith
Sweet. Target for 2.9?

Jul 22 21:39:39 2009
MarkJaquith
Or 3.0?

Jul 22 21:39:45 2009
ddebernardy
2.9

Jul 22 21:39:49 2009
hakre
3.0

Jul 22 21:39:58 2009
hakre
2.9 is bugfix or is there any 2.8.3 planned?

Jul 22 21:40:01 2009
hakre
^^

Jul 22 21:40:14 2009
scribu
3.0

Jul 22 21:40:23 2009
DD32
unless 3.0 is going PHP5.. then 2.9 seems right.. (2.9 is not a bugfix, thats only x.x.ys)

Jul 22 21:40:30 2009
junsuijin
2.9

Jul 22 21:40:34 2009
Viper007Bond
2.9 isn't bug... yeah

Jul 22 21:40:36 2009
MarkJaquith
hakre: 2.8.3 as needed for huge bugs or security.

[PaulCunningham]

Capability = the permission or ability to do something
Role = a group of capabilities

Non-WordPress example to try and explain it...

Capabilities:
- look at door
- unlock door
- open/close door
- lock door

Roles:
- Door Viewer
- Door User
- Door Admin

Door Viewer capabilities:
- look at door

Door User capabilities
- look at door
- open/close door

Door Admin capabilities
- look at door
- open/close door
- unlock door
- lock door

User "Paul" is a Door Admin, user "Jeffro" is a Door User. Now lets say Paul wants to grant Jeffro the ability to lock an unlocked door, but not unlock a locked door. There is no existing role for that.

So we create a new Role and call it say Door SuperUser, and grant it:
- look at door
- open/close door
- lock door

Now I guess we can basically do all that already with core WP + various plugins, but the scalability problem is probably due to the current ability to assign more than one Role to a user (eg Jeffro is Door Viewer and Door User), and to directly assign Capabilities to a user (eg Jeffro has Door Viewer role plus directly assigned Lock/Unlock Door capability, instead of a single role encompassing all of those capabilities).

The above would (I imagine) cause serious problems filtering user lists in various admin panels, or at the very least make the SQL query more complex and more resource intensive than the new system would be. Each user object's security attribute in the WP DB would be a single value of the appropriate Role ID#, rather than a blob of (potentially) multiple Roles and Capabilities.

The plugin breakage would be for the serious user management plugins and since Matt refers to them as mostly commercial ones I guess they mean the likes of Amember and WP-Wishlist. Those plugin devs will simply have to update to remain compatible, but thats okay because thats the kind of support their users pay for.

Hope that makes sense and I've understood it correctly, otherwise I'm sure another forum member will straighten me out!

[Jeffro]

I'm hoping your explanation is correct because I was able to understand that with no problems. It's like you took what they said and translated it for normalfolk :)

[Ryan]

I got last past way through all that. But hopefully whatever it is they're trying to do does not make it even more difficult to control user management in WordPress. WordPress is quite limited in the way it handles user permissions and I wouldn't like to see it become worse than it already is just because of some scale-up issues.

[JohnM]

Dev talk always seems too code/problem orientated instead of focusing on quality of features. Arguments like no one uses it are not valid arguments because the state of role plugins and the fact that they dont actually have the insight.

I hope Justins plugin ( in the making ) survives these changes, cause I want more features, not less, and usable administration.

[andrea_r]

The above would (I imagine) cause serious problems filtering user lists in various admin panels, or at the very least make the SQL query more complex and more resource intensive than the new system would be. Each user object's security attribute in the WP DB would be a single value of the appropriate Role ID#, rather than a blob of (potentially) multiple Roles and Capabilities.

Yep, and user management has always been an issue in WPMU. With the upcoming merge, and throwing multiple blogs in the mix, can you see how the current user roles & capabilites throws a monkey wrench in there?

What they're proposing is much, much more flexible and streamlined.

[Otto]

What they're proposing is actually less flexible, but it scales better and frankly makes more sense.

Like Mark said, almost nobody uses multiple roles per user or individual caps per user. It makes far more sense to sort your users into a bunch of groups and then give those groups capabilities.

If somebody needs new caps, you bump them up a group or you make a new group with the caps they need and put them in it. Plus, if one person needs a cap, then the likelyhood is that more than one person fits into that group as well.

This simplification of the role/cap system means that it's more likely role management will move into core, especially with the MU merge where it's more likely that you need to do that sort of thing.

[chipbennett]

What they're proposing is actually less flexible, but it scales better and frankly makes more sense.

Like Mark said, almost nobody uses multiple roles per user or individual caps per user. It makes far more sense to sort your users into a bunch of groups and then give those groups capabilities.

If somebody needs new caps, you bump them up a group or you make a new group with the caps they need and put them in it. Plus, if one person needs a cap, then the likelyhood is that more than one person fits into that group as well.

This simplification of the role/cap system means that it's more likely role management will move into core, especially with the MU merge where it's more likely that you need to do that sort of thing.

I agree, Otto, except that I don't see it as less flexible, but rather as changing the functionality to be equally flexible, but different. Individual users can still have unique capability sets; only now those unique capability sets will have to be defined as a unique user role, and a user set to that role.

Even if every user is defined a unique user role, this method has to be far more scalable. Consider Mark's reference of scalability issues at 20-30K users. I would think that the performance/efficiency gains would be astronomical at that scale.

And even for much smaller user bases, this method, it would seem, makes user management much easier (although it will be up to the user/user-role administrator to implement a good system for defining/naming/assigning user roles).

[Ryan]

What they're proposing is actually less flexible, but it scales better and frankly makes more sense.

Like Mark said, almost nobody uses multiple roles per user or individual caps per user. It makes far more sense to sort your users into a bunch of groups and then give those groups capabilities.

I don't fully understand much of the content of this topic. But it does concern me a little that they may be removing functionality that would help create a proper user permissions system.

The current roles and capabilities system isn't used often in WordPress simply because it isn't up to scratch for many tasks.


I could easily be way off-base and this won't affect the actual potential functionality of the system at all. I have no idea.

[PaulCunningham]

What they're proposing is actually less flexible, but it scales better and frankly makes more sense.

I'm with chip, I think it is as flexible but will prevent scalability problems because it constrains users to a more efficient way of assigning permissions within WordPress. In other words, by preventing users from being able to assign a haphazard set of capabilities directly to a user without properly defining that group of capabilities as a Role, you no longer have to account for that usage pattern in the WP code itself. This means the code can be optimised and made more efficient for larger user databases to resolve the scaling problems they're hitting on those sites.

Put yourself in the devs shoes I guess - a small site with few users might think its a pain to have to define Roles properly in future, but a large scale site with thousands of registered users, dozens of contributors, several editors, and a group of admins, will appreciate the better performance and thats the kind of thing that would stop them moving away from WP to another platform that handles the scale better.

A bit of pain during the transition? Probably. Thats WordPress though (how many new admin interfaces have we all transitioned through over the years!).