[wp-hackers] current_user_can() and roles ?

[Moya, Eddie]

I agree, at the very least, every item in the admin menu should be different
capabilities. Ideally, most activities on each page would have a capability
of their own, or some equivalent that would allow for fine grain
permissions.  

If or until such changes are made to wordpress, the only "clean(er)" (if you
can it that) solution might be to actually have a plugin replace the entire
code of the areas in question, just to that you can put in your own caps.
Not useful once upgrades come around, but at least it would keep people from
changing the core files while adding as much specificity to the capabilities
as I want.

That's an interesting idea and all, but for now, its all edited core files.
Thanks for the feedback, good to know I wasn't completely off base.


On 1/6/10 3:46 PM, "Dion Hulse (dd32)" <wordpress at dd32.id.au> wrote:

> 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
>> 
>