[wp-hackers] User Capabilities

[Ryan Boren]

On Fri, 2005-07-01 at 15:18 -0400, David Chait wrote:
> There obviously would be a need for some plugins to possibly be 
> available/work for editors/users, while others would be reserved for pure 
> top-level Admins.  So there might need to be some other roles defined that 
> help better for plugins that say show statistics (referrers/stats), or 
> anti-spam stuff, etc.  As well as say a database backup/restore plugin.

Capabilities are easily added. We'll need to do some mulling and decide
what the default capability set should be.

> Also, can we differentiate visitor (unregistered) vs subscriber 
> (registered)?

An unregistered user won't get past the login.  I don't think we need to
worry with them.  Let's call my proposed 'visitor' role 'subscriber'
instead.  That sounds better.

Also, an 'inactive' role that has no capabilities could be used for
retired users who are no longer contributing.  This would deactivate
them without deleting them.

> And I assume admin panels would potentially then depend on what roles you 
> have?  Might need some extra roles as above to help break down what kind of 
> administrative tasks are outside the norm.

Sure. 

> There should also always be an Admin 'meta role' that doesn't need explicit 
> definition of every possible access -- rather, it should be inherently 
> all-access.  God forbid we start having plugins that create new access 
> roles, there should always be an administrator role that can access 
> everything, period. ;)

Yeah, that will need discussion, and plugins will need to show some
restraint. :-)

Ryan

> ----- Original Message ----- 
> From: "Ryan Boren" <ryan at boren.nu>
> To: <wp-hackers at lists.automattic.com>
> Sent: Friday, July 01, 2005 11:08 AM
> Subject: Re: [wp-hackers] User Capabilities
> 
> 
> > Yeah, we'll need stuff like this for backwards compat.  One specific
> > instance is plugins adding new admin menus.   They currently specify a
> > user level.  They need to specify capabilities instead.  To illustrate,
> > here's how the theme menu is currently constructed in menu.php.