Capabilities and Plugins

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Capabilities and Plugins

Mark Jaquith
As it is now, there is no way for a third party role manager plugin  
(like Owen's... is there another one?) to know about the capabilities  
that a plugin uses unless that plugin adds the capability to an  
existing role.

I can think of two solutions:

An easy way to add the plugin's capability to all roles with  
manage_options capability (which is, IMO, the best way to determine  
the most authoritative users on the WP install).  Then, the role  
manager plugin will display that capability and it can be added to  
other roles.

Or, create a new function that allows plugins to register their  
capabilities (in memory).  Then, a role manager plugin could merge  
capabilities defined in the database with default capabilities plus  
capabilities registered by plugins on the fly.

As it is, the plugin would have to have its own mini role management  
code, which seems wasteful to me.

--
Mark Jaquith
http://txfx.net/


_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Capabilities and Plugins

Sam Angove
On 3/5/06, Mark Jaquith <[hidden email]> wrote:
> As it is now, there is no way for a third party role manager plugin
> (like Owen's... is there another one?) to know about the capabilities
> that a plugin uses unless that plugin adds the capability to an
> existing role.

Just curious, but why aren't plugins granting caps to the
administrator role as a matter of course? They'll be able to grant it
to themselves anyway, after all, and it seems like a good
policy/best-practice.

(And there's always $grant = false, so adding a cap to the role
doesn't have to mean granting it. )

>
> An easy way to add the plugin's capability to all roles with
> manage_options capability [...]

That'd be pretty cool as a generic function -- let a plugin give all
roles with `manage_comments` the `ajax_delete_comment` cap, say. I'd
use it, though for the time being I'm satisfied with something like

        foreach ( array_keys($wp_roles->get_names()) as $role_name ) {
                $role =& get_role($role_name);
                if ( $role->has_cap('manage_options') ) {
                        $role->add_cap('some_plugin_cap');
                }
        }
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Capabilities and Plugins

Owen Winkler
In reply to this post by Mark Jaquith
Mark Jaquith wrote:
> Or, create a new function that allows plugins to register their
> capabilities (in memory).  Then, a role manager plugin could merge
> capabilities defined in the database with default capabilities plus
> capabilities registered by plugins on the fly.

In my Role Manager, I have added a hook that allows plugins to register
their own caps for application to roles and users.  This is from the
Role Manager documentation (http://redalt.com/wiki/Role+Manager):

add_filter('capabilities_list', 'add_my_caps');
function add_my_caps($caps) {
$caps[] = 'my_custom_cap1';
$caps[] = 'my_custom_cap2';
return $caps;
}

If the core were to do this, it would need to fill the caps list with
all of the built-in caps.

Owen
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Capabilities and Plugins

Mark Jaquith
On Mar 5, 2006, at 9:11 AM, Owen Winkler wrote:

> In my Role Manager, I have added a hook that allows plugins to  
> register their own caps for application to roles and users.
[...]
>
> If the core were to do this, it would need to fill the caps list  
> with all of the built-in caps.

It would be nice if the core could have a function to return an array  
of all hooks (default + extra ones registered by plugins).  Your  
plugin may be the only one now that provides role management  
capability, but that might not be the case in the future.  There  
should be a way for plugins to register their capabilities so that  
whatever role manager is being used can access them.  I'm fine with  
taking the option_name and hook that you're using and moving them  
into core.

--
Mark Jaquith
http://txfx.net/


_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Capabilities and Plugins

Owen Winkler
In reply to this post by Sam Angove
Sam Angove wrote:

> On 3/5/06, Mark Jaquith <[hidden email]> wrote:
>> As it is now, there is no way for a third party role manager plugin
>> (like Owen's... is there another one?) to know about the capabilities
>> that a plugin uses unless that plugin adds the capability to an
>> existing role.
>
> Just curious, but why aren't plugins granting caps to the
> administrator role as a matter of course? They'll be able to grant it
> to themselves anyway, after all, and it seems like a good
> policy/best-practice.

Because there is no guarantee that an "administrator" role exists.
Determining which role functions in an administrative capacity can be
problematic.

>> An easy way to add the plugin's capability to all roles with
>> manage_options capability [...]

Granting caps automatically sounds like a bad idea to me.  Logically
speaking, why have a new capability at all, if you're going to grant the
cap to only those roles that already have manage_options?

Owen
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Capabilities and Plugins

Mark Jaquith
On Mar 5, 2006, at 9:19 AM, Owen Winkler wrote:

> Granting caps automatically sounds like a bad idea to me.  
> Logically speaking, why have a new capability at all, if you're  
> going to grant the cap to only those roles that already have  
> manage_options?

Well, it could be used as a "starting point" so that the capability  
could be delivered to "lesser" users.   Having a method in the core  
for registering capabilities would be much better, of course.

--
Mark Jaquith
http://txfx.net/


_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Capabilities and Plugins

David House
In reply to this post by Owen Winkler
On 05/03/06, Owen Winkler <[hidden email]> wrote:
> Because there is no guarantee that an "administrator" role exists.
> Determining which role functions in an administrative capacity can be
> problematic.

Mark Jaquith and I discussed this last night on #wordpress-dev and
thought it might be nice to assign some special status to
administrator (or possibly have some hidden role, 'superrole', 'root'
or something) that acts as a sink for all possible caps, along with a
get_superrole() function. This would make it nice and easy to tell
which caps are available, and might allow easier administration if
special privs are needed.

On the other hand, that might be overkill if we allow some method of
registering caps without tying them down to a specific role.

Actually, now I think about it, it doesn't make any sense to have a
cap which isn't tied to a role. If plugins don't want any existing
roles to have their cap, just create a new role and assign the cap to
that. Then Role Manager picks up that cap (if I remember the code
correctly). Or am I missing something?

--
-David House, [hidden email], http://xmouse.ithium.net
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Capabilities and Plugins

Mark Jaquith
On Mar 5, 2006, at 9:34 AM, David House wrote:

> Mark Jaquith and I discussed this last night on #wordpress-dev and
> thought it might be nice to assign some special status to
> administrator (or possibly have some hidden role, 'superrole', 'root'
> or something) that acts as a sink for all possible caps, along with a
> get_superrole() function. This would make it nice and easy to tell
> which caps are available, and might allow easier administration if
> special privs are needed.

I think I've changed my mind on this. :-)

> On the other hand, that might be overkill if we allow some method of
> registering caps without tying them down to a specific role.

Precisely why I changed my mind.

> Actually, now I think about it, it doesn't make any sense to have a
> cap which isn't tied to a role.

I think it makes less sense to presume to guess which roles a the WP  
operator wants to have this new capability.

> If plugins don't want any existing
> roles to have their cap, just create a new role and assign the cap to
> that. Then Role Manager picks up that cap (if I remember the code
> correctly). Or am I missing something?

Should work, but it seems silly to create a role only as a container  
of a capability.  Why not just create a mechanism by which plugin  
authors can register their capability, and then let people add that  
capability to an existing role?

In the plugin, you could do something like register_cap
('some_cool_thing'); register_cap() would look at an existing array  
in the options table (a namespaced option, just like the one that  
holds roles) and if it doesn't exist, it adds it.  Then there could  
be a function like get_all_caps() that would return an array of all  
the default WP capabilities, plus all capabilities stored in that  
option.

If we used the same option that Owen is using now, we could probably  
even rig it so that older versions of his plugin would continue to work.

And because there'd be a universal method of adding/getting  
capabilities, plugin authors could just use current_user_can
('my_cap') for their logic checks, and then in their installation  
instructions say "Add the "my_cap" capability to the users or roles  
to want to be able to use this plugin" and they could link to a codex  
page that has a list of role manager plugins.

How's that sound?

--
Mark Jaquith
http://txfx.net/


_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Capabilities and Plugins

David House
On 05/03/06, Mark Jaquith <[hidden email]> wrote:
> How's that sound?

It's still a possbility that the plugin would create a role to
represent people that should be allowed into the functionality that
plugin provides. The admin would then assign specific users that role
(remember users can have multiple roles).

But I still prefer some register_cap() func, for flexibility's sake.
In the end, going with that previous method is just going to result in
a lot of almost-pointless roles.

+1.

--
-David House, [hidden email], http://xmouse.ithium.net
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers