[wp-trac] Re: [WordPress Trac] #2531: Functions for registering additional capabilities and getting a list of all capabilities

[WordPress Trac]

#2531: Functions for registering additional capabilities and getting a list of all
capabilities
----------------------------+-----------------------------------------------
       Id:  2531            |      Status:  new                     
Component:  Administration  |    Modified:  Wed Apr 26 04:04:21 2006
 Severity:  normal          |   Milestone:  2.1                     
 Priority:  normal          |     Version:  2.0.1                   
    Owner:  anonymous       |    Reporter:  markjaquith             
----------------------------+-----------------------------------------------
Comment (by ringmaster):

 What we have now is pretty simple.  I'm not sure how
 current_user_can('do_something') can be much more clear.  In what way are
 you suggesting that it's not simple?  Nevermind that most ACL systems work
 just like WP roles and capabilities, so the knowledge of the workings of
 similar systems ports to WordPress.

 What is currently lacking in the core is a good way to let users manually
 set capabilities as required by plugins.  Also, features to allow access
 to plugins for setting these capabilities are not as apparent as they
 might be.  Remember though, the capabilities system was designed and
 implemented knowing that none of those things would exist in that release.
 We should now address those issues.

 There are several plugins that were not written by core hackers that make
 use of the caps system.  I'm not sure what would give the impression that
 the caps system is a barrier to developers.

 The proposed 1-6 system seems less understandable than the caps system.
 How do you permit a single user access to something that is typically not
 permitted to users of their assigned role?  How does the number mean
 anything to what functions you are allowed to access?  The inability to
 answer this question is the exact reason why we ditched the userlevel
 nonsense in the first place.

 WordPress is not WordPress MU.  If the capabilities system is incompatible
 with MU (it isn't), then perhaps MU devs should consider using something
 that works better for them.  Providing for discrete capabilities for
 WordPress when used as a CMS is something that we would be remiss to
 remove just to gain speed improvements in some other projects, which would
 likely not be used as a CMS.

 This is the first complaint I've heard about the capabilities system other
 than from folks who were used to having arbitrarily defined hierarchical
 levels, and I'm shocked.  I'm curious what code you've attempted to write
 with permissions that has been so difficult that would lead you to this
 severely regressive suggestion.

-- 
Ticket URL: <http://trac.wordpress.org/ticket/2531>
WordPress Trac <http://wordpress.org/>
WordPress blogging software