[wp-hackers] current_user_can() and roles ?

[Dion Hulse (dd32)]

Theres 2 approaches that can be taken here.

The caps like that could become meta_caps, Ie. you called  
current_user_can('switch_themes', 'widgets'); which could be different  
 from current_user_can('switch_themes', 'themes');

But that requires Core changes.

The better option is to have all these functionalities on their own  
capability. For example, I think the Core upgrade is using the Plugin  
upgrade cap. They should be on different capabilities in my opinion.

Might be worth a trac ticket to add extra caps for all these, so that the  
functionality can be disabled/controlled properly on a per-admin-feature  
basis.


On Thu, 07 Jan 2010 08:42:18 +1100, Moya, Eddie <emoya at tribune.com> wrote:

> Since there is a conversation going on about roles and capabilities, I  
> would
> like to pose another question. What options do we have for granulizing   
> of
> the capabilities?
>
> For example, I needed to create a new role that would be able to edit
> widgets, but not themes. Both use the capability "switch themes". Its
> possible to change the admin menu item capabilities through the global  
> $menu
> and $submenu arrays. However, this doesn't change the capabilities on the
> pages themselves, which leaves significant security holes.
>
> Due to time constraints on the project, the solution ended up being that  
> we
> begrudgingly edited the files themselves to change those hardcoded
> capabilities.
>
> Is there any clean solution to this? The only partial comes where there  
> are
> get variables  (such as 'import') we can retrieve to distinguish a page,  
> or
> a part of a page, from another, at which point we can trigger a check
> against our custom capability. Is there any real solution to this, or  
> are we
> stuck editing the otherwise hardcoded caps?
>
>
> On 1/6/10 3:23 PM, "Dion Hulse (dd32)" <wordpress at dd32.id.au> wrote:
>
>> Also, Please do not use the level_* capabilities.
>> They're been deprecated since 2.0 and really need to go away (3.0
>> intrduces a warning that they're deprecated too).
>>
>> Rely on the string caps instead, for example, 'manage_options' is a  
>> pretty
>> good choice most of the time, only admins have that, and that suits 90%  
>> of
>> plugins.
>>
>> On Thu, 07 Jan 2010 07:14:27 +1100, Stephen Rider
>> <wp-hackers at striderweb.com> wrote:
>>
>>>
>>> On Jan 6, 2010, at 1:33 PM, Frank Bueltge wrote:
>>>
>>>> The admin give other users a rolle, not rights and in my plugin it os:
>>>> the admin select the role and i will check only for this. Maybe i must
>>>> add a new capabilitie to the role, the select the admin. And then i
>>>> can check for the new object. A also then it is possiblt to add this
>>>> object to a new role "superman".
>>>
>>> Generally I have found that an existing capability is "close enough" to
>>> the ability I want to add.  If your plugin is doing something truly
>>> unique, though, you may think about actually adding a new capability.
>>>
>>> If you do that, don't forget to assign that Capability to one or more
>>> Roles so somebody can actually do the thing!  ;-)
>>>
>>> (I'm actually going to have to do this soon with a plugin that I don't
>>> even want *admins* to have direct access to.  I believe I'm going to  
>>> end
>>> up creating a new capability and new "super admin" role....)
>>>
>>> Regards,
>>>
>>> Stephen
>>>
>>> _______________________________________________
>>> wp-hackers mailing list
>>> wp-hackers at lists.automattic.com
>>> http://lists.automattic.com/mailman/listinfo/wp-hackers
>>>
>>
>
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>


-- 
Dion Hulse / dd32

Contact:
  e: contact at dd32.id.au
  msn: msn at d32.id.au
  skype: theonly_dd32
Web: http://dd32.id.au/