[wp-trac] Re: [WordPress Trac] #5255: Simplify role/capability for easier cap => user lookups

[WordPress Trac]

#5255: Simplify role/capability for easier cap => user lookups
-------------------------+--------------------------------------------------
 Reporter:  markjaquith  |        Owner:  anonymous
     Type:  task         |       Status:  new      
 Priority:  normal       |    Milestone:  2.4      
Component:  General      |      Version:           
 Severity:  normal       |   Resolution:           
 Keywords:               |  
-------------------------+--------------------------------------------------
Comment (by markjaquith):

 Replying to [comment:8 filosofo]:
 > First, it's not clear to me what you're proposing.  Ryan says above that
 "If you want to change what a user can do, give the user a new role with a
 new set of capabilities."  That sounds to me like you can't change a
 role's existing capabilities; instead, you have to create a new role with
 its own capabilities.

 Two different scenarios:

  1. You want to add Cap_X to User_Y
  1. You want to add Cap_X to Role_Z

 Ryan is saying that what would change in order to do #1 is that you would
 need to create a new role in order to isolate the changes for that user.
 #2 doesn't change at all... so you'll still be able to change an existing
 role's capabilities.

 > Second, even if the proposed system does allow one to add capabilities
 to roles, that seems of trivial use. Let's say my plugin checks for its
 "edit_video" capability.  If I can add that capability only on a per-role
 basis, what's the point?  Instead of adding "edit_video" to all "editors,"
 I should just check whether someone is an "editor."  The particular
 capability has become superfluous.

 Checking the role assumes that the role exists, and that its meaning has
 not changed.  That's not necessarily the case.  So it's much better for a
 plugin to define new capabilities and let the user decide which roles
 should get those capabilities.

 > Instead, a more likely--and useful--situation is that I want to assign
 the "edit_video" capability in a way that doesn't map neatly to existing
 roles. So for example Bob who is an "author" can "edit_video," as well as
 Mary an "editor," but not other editors or authors.

 If it doesn't map neatly to existing roles, yeah, you'd need a new role.
 Not ideal for that scenario the first time you need to do it, but it
 scales a lot better if you create a new role, because you can perform bulk
 operations on that role.  "Add foo_bar to everyone with edit_video" is a
 lot easier if you only have to do it for each role with edit_video, and
 not every individual user.  Obviously there are pros and cons, but I think
 that few people are going to want a large number of distinct capability
 combinations.

 > Besides, we don't really use roles that much, at least in core WP.
 Grepping through 2.3 I don't see anywhere that we check for users having
 the role of 'administrator' or 'editor.'  Rather, we check capabilities.

 Roles are containers of capabilities, for grouping purposes.  They don't
 have inherent meaning.  That's why we don't do
 {{{current_user_can('editor')}}}.

 > > If each user has a distinct role, then yeah, you'll have a user:role
 ratio of 1.  That's not the common case in multi-user installs.
 >
 > Right--what I'm saying is that if users can have only one role, then
 that's the kind of situation you could end up with.  If I want Bob to
 "edit_video" and have all the other capabilities of an author, but I don't
 want other authors to have the "edit_video" cap, then I'll have to create
 a new role with author capabilities + the "edit_video" capability, and
 assign it to Bob.  Then if another plugin wants to assign, say, the
 "make_podcast" capability without giving it to everyone within an existing
 role, that plugin will have to generate a new role. It seems like the
 following would be some of the consequences to this arrangement:

 >  * Plugins clutter up the system with new roles for what would otherwise
 be slight changes (adding a capability).

 Plugins shouldn't add new roles for this reason.  Instead, they should
 allow users to make the choice of adding the new capability to existing
 roles and/or new roles.  The problem there is that role management
 requires a plugin.  Perhaps that needs to change.  And it's certainly more
 likely to happen if our cap/role system trims some of the fat.

 >  * Roles become meaningless.  I can't assume that Bob is an author
 anymore, as he might have become the new role that combines the
 capabilities of an author with "edit_video."  So it does no good to test
 someone's role.

 Roles '''are''' meaningless.  They're only containers of capabilities.

-- 
Ticket URL: <http://trac.wordpress.org/ticket/5255#comment:10>
WordPress Trac <http://trac.wordpress.org/>
WordPress blogging software