[wp-trac] [WordPress Trac] #10201: Switch roles to use single role, and no user-specific caps

[WordPress Trac]

#10201: Switch roles to use single role, and no user-specific caps
-------------------------------+--------------------------------------------
 Reporter:  Denis-de-Bernardy  |       Owner:                
     Type:  task (blessed)     |      Status:  assigned      
 Priority:  normal             |   Milestone:  Future Release
Component:  Role/Capability    |     Version:  2.8           
 Severity:  normal             |    Keywords:  2nd-opinion   
-------------------------------+--------------------------------------------

Comment(by apljdi):

 Replying to [comment:35 dd32]:
 > Roles are primary to group capabilities to a user, And giving a user a
 cap is a secondary thing, if the role doesnt manage 100%.

 I realize that this is how it currently works, but this is also what seems
 wrong to me. ''What'' a user can do is the important part. That is, a
 user's capabilities is the critical thing. Roles are just convenient ways
 to assign those capabilities. Really, a Role with no capabilities is just
 nothing. Its meaningless. So why such a strong focus on Roles? Why tie
 capabilities to Roles?

 > You'd be affected detrimentally by this change, you would HAVE to have
 umpteen roles, no question about it...

 Yes, I know. Back a few releases ago I was looking at having to create a
 kind of capability system because the old style user level system wasn't
 flexible enough. The Role system got revamped. It became more flexible,
 more powerful. It became quite useful, even if it wasn't being used much
 as some here have suggested. Now, it looks to me like we are heading back
 to that inflexible and inadequate user_level system-- maybe not
 completely, but significantly. Why?

 > removing the ability to have multiple role and allowing to have user
 specific caps wouldnt really add that much performance benefit IMO.

 I'm not just arguing about performance improvements, though the current
 system doesn't perform very well, which is how I came to this thread in
 the first place actually. I'm also arguing for a cap/role system that is
 powerful and flexible enough that you don't have to essentially create a
 second system in third party code to do anything interesting.

 I don't see why both multiple Role and user specific capabilities can't be
 preserved, though I see less use for multiple roles. The performance
 problem doesn't come from the fact that multiple roles can be assigned or
 that user specific capabilities can be assigned. The performance problem
 comes from how the current system was designed.

 I favor a scheme similar to one already outlined in
 [http://core.trac.wordpress.org/ticket/10201#comment:15 this thread]

 1) users can have one role[[BR]]
 2) roles can have multiple caps[[BR]]
 3) roles and their caps are stored as a serialized array in the options
 table[[BR]]
 4) for each user, we store the role as a varchar in the user_meta
 table[[BR]]
 5) to get all users with a role or a cap, we query the user_meta table
 directly[[BR]]

 But done this way, there is no good reason for item 1. You can store two
 roles just as easily as one and pull them both back out reasonably
 quickly. Items 2 and 3 can stay. If we accept item 4 there is no reason
 not to also store user specific capabilities in the usermeta table. But
 perplexingly, item 5 doesn't make sense if both roles and caps are not
 stored in the usermeta table in a varchar column like number item 4 has
 roles being stored. Sure, you can "LIKE '%cap%'" but that is no better
 than what is possible right now.

 So it looks to me like you can:

 1) Store user role(s) in the usermeta table as a varchar: wp_user_role =
 "editor"[[BR]]
 2) Also store capabilities in the usermeta table as a varchar: wp_user_cap
 = "read", wp_user_cap = "edit_posts", etc[[BR]]
 3) Have roles and their caps stored as a serialized array in the options
 table as a quick an easy way to assign multiple capabilities, but that's
 really what it is-- a shortcut method for assigning capabilities.[[BR]]
 Then,[[BR]]
 4) "to get all users with a role or a cap, we query the user_meta table
 directly"[[BR]]

 You preserve everything and simplify everything at the same time. I've
 been playing with this a bit already and with a database of 4750 or so
 users this scheme adds quite few rows to the usermeta table-- about 3 per
 user in my case since most are subscribers-- but the 'get all users in
 somerole' or the 'get all users with somecap' queries (on an indexed
 varchar column that I added) are about 6.4 times faster than I can get
 them with a "LIKE '%...%"' query. And there is no complicated array
 parsing, just simple array parsing. Adding a new table might ramp up the
 performance but I haven't tested that, and I'm not sure the extra
 complexity is worth it.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/10201#comment:36>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software