[wp-trac] Re: [WordPress Trac] #2775: Ability for all users to add users of lesser cabable roles

[WordPress Trac]

#2775: Ability for all users to add users of lesser cabable roles
----------------------------+-----------------------------------------------
       Id:  2775            |      Status:  new                     
Component:  Administration  |    Modified:  Sat Jun  3 01:29:49 2006
 Severity:  enhancement     |   Milestone:                          
 Priority:  normal          |     Version:  2.1                     
    Owner:  anonymous       |    Reporter:  doit-cu                 
----------------------------+-----------------------------------------------
Comment (by doit-cu):

 I guess I was thinking more along the lines that a user should not be able
 to edit a user who has a capability that the editing user does not have.
 So, for instance, if role foo has capabilities biz and baz, and role bar
 has capabilities biz, baz, and bam, foo should not be able to edit bar,
 but bar should be able to edit foo.  The reasoning in my mind is that bar
 is more trusted in the system, having the ability to "bam."  Also, if gaz
 has capability qux, and zxc has the capability asd, neither should be able
 to edit the other.

 The real point of what I'm trying for in my instance is not really editing
 though, but the ability to create users with a subset (defined as a role)
 of capabilities.  Now this ability can be added in to the wordpress code
 base without changing the default functionality- as far as I know, only
 administrator has the edit_users capability out of the gate.  I guess it
 seems to me that user management should be a bit more granular than an
 on/off switch.

 I agree that there should not be a hierarchy set up between roles, and I
 can understand that this might not be desireable default behavior.  What
 this would do though is make the application more amenable to Plugins and
 other "aftermarket" modifications.  I believe it will make the application
 more customizable, rather than simply being a customization in and of
 itself.

 I have the code all written up, I just need to drop in some cleaner UI
 errors as opposed to simply die().  I'll upload a diff later this weekend
 and see what you all think... this seems to be a difficult one for me to
 get my choice of words correct on.

 Barring that, I think the cleanest way to provide a plugin with this
 ability would be to allow redefinition of the current_user_can function.
 users.php and user-edit.php would need to pass in a WP_User object or an
 array of said objects by reference (so that you can clean out the denied
 users while maintaining the allowed users) into current_user_can in order
 for that to be of any real use.  I still see a problem here, because if
 someone has edit_user and activate_plugins, they could turn off the
 filtering plugin and be able to edit and users again.  The protection
 should, in my opinion, really be a part of the application.

 Finally, thank you both for your time on this.

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