[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:  enhancement        |      Status:  assigned
 Priority:  normal             |   Milestone:  Future Release
Component:  Role/Capability    |     Version:  2.8
 Severity:  normal             |  Resolution:
 Keywords:  early              |
-------------------------------+-----------------------------
Changes (by jeremyclarke):

 * cc: jer@… (added)


Comment:

 I think keeping multiple-roles is vital if you remove per-user-caps. I
 agree that no one uses them now but people definitely use per-user caps if
 they are available. We did so in the past when the Role Manager plugin
 still worked because it offered the ability. Custom caps keep your roles
 system clean and simple while letting you satisfy edge-cases (like trusted
 authors who need to edit categories or widgets but not options).


 In recent years no plugins have exposed the custom-caps functionality,
 probably because, as Nacin points out in the post linked above, the
 current Roles system is not only complex, it is buggy and broken. I've
 never used a plugin that properly and buglessly implemented custom caps
 /anti-caps, which I think is a big factor in their unpopularity. If there
 had been a core plugin that exposed the custom-caps and multiple-roles
 functionality (and fixes in core to support it actually working) I think
 the numbers would play out differently. I also think such a core plugin is
 exactly what core-plugins should be about: exposing functionality that is
 hidden from default installs to reduce UI clutter.

 A good argument in favor of multiple-roles is that after creating a one-
 time custom role for a single user (say, author+widget manager) you then
 have to remember/forget to make changes to that custom role when you make
 changes to the 'author' role (e.g. adding the 'unfiltered_html' ability
 for authors, which would result in your especially-trusted author being
 the only one on the site without that cap, leading to frustrating
 debugging experiences).

 There is inherent value to keeping all users in a simple set of common
 roles and not forcing users out of the common roles just to give them a
 special capability. In many cases having the users in clean roles also
 helps institutionally, giving managers the ability to use roles as a way
 of filtering groups within their organization (i.e. if you know all
 editors are paid and authors aren't then keeping the roles system clean
 gives you a lot of power you don't have otherwise). Multi-roles also
 offers the possibility of creating institutional roles on TOP of the
 generic ones (i.e. one user is author+employee, another is admin+employee
 and another is author+community). This would let the roles system be used
 for grouping users together for non-permissions purposes without having a
 whole separate system that duplicates most of the functionality of Roles.

 The model of having a "just_edit_widgets" role to supplement an author or
 editor makes a lot of sense to me. It is a fair compromise for those who
 don't want to give up per-user-caps and from the discussions above it
 sounds like it is doable within the best ideas for how to update the
 system from a code perspective.

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