[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 filosofo):

 Replying to [comment:7 markjaquith]:
 > Replying to [comment:6 filosofo]:
 > > How would you get around the following two problems?  Currently, if a
 plugin wants to add a capability to a role, say "cap_X", it degrades
 nicely when the plugin is no longer in use--i.e. having an unused
 capability doesn't hurt anything. However, under the proposed system one
 would have to create a new role for each new combination of capabilities.
 If I add "cap_X" to all my administrators, then they will no longer each
 be an "administrator"; they will be something plugin-specific.
 >
 > You don't add cap_X to your administrators, you add it to the
 administrator role, and all of your users with that role get that
 capability because it is contained in the role they're using.

 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.

 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.

 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.

 Replying to [comment:7 markjaquith]:
 > Replying to [comment:6 filosofo]:
 > > Why not just drop roles entirely, and list capabilities on separate
 usermeta rows?  Then if you want to find out who can edit posts or
 whatever, it's a simple query.
 >
 > Because then you lose the ability to modify roles and have all people
 using that role get the modification.

 We could get around that by making roles into capabilities; then adding a
 capability to users who can "administrate" would be as simple as 1.
 changing the default caps for administrators (for future new users) and 2.
 adding the capability to all users who currently can administrate.

 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.

 Replying to [comment:7 markjaquith]:
 > Replying to [comment:6 filosofo]:
 > > The second problem is getting two different plugins that add
 capabilities to work together.  One wants to give a user "cap_X," and the
 other wants to give the same user "cap_Y", so which gets to define the
 role?  It seems to me that in some fairly common scenarios the number of
 distinct roles could approach the number of users.
 >
 > 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).
  * 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.
  * Plugins' different roles collide.

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