On Aug 5, 8:34 am, Olemis Lang <[email protected]> wrote:
> On Tue, Aug 4, 2009 at 10:21 PM,jevans<[email protected]> wrote:
>
> > On Aug 4, 9:27 am, yoheeb <[email protected]> wrote:
> >> On Aug 4, 7:18 am, Olemis Lang <[email protected]> wrote:
> >> > On Mon, Aug 3, 2009 at 6:21 PM, Ryan Ollos<[email protected]> wrote:
> >> >
> >> > > The problem I have is that I want all users to see the tab, but I have
> >> > > multiple groups with non-overlappingpermissions, and currently no
> >> > > single permission that I can assign to all users without granting some
> >> > > of those users access to resources I'd prefer them to not see,
>
> >> > AFAICS what you need is to define groups of users having
> >> > similarpermissions.
>
> >> you need to implement a custom permission handler:
>
> > It would be nice if the various plug-in's that ask for permissions for
> > whatever they do could/would accept group names as well as actual
> > permissions.
>
> IMHO (I'm not a core Trac dev) this means to add unnecessary
> complexity to the permissions systems. Why ?
>
> - User Groups depend *ONLY* on the characteristics of the deployment
> environment and the policies applied in each particular scenario, and thus
> they are beyond the control of the plugin developper
> - Plugin developpers are only interested in whether an action can be
> performed or not (i.e. actions | permission names ;o) and not in the
> particular arrangements, affiliations, setup and further details
> inherent to the
> specific deployment environment.
I'm not sure if you understood my suggestion. I'm only wondering if
when plug-in's ask what permission to check for some action (I'm
thinking long the lines of the various nav bar plug-in's as originally
mentioned), they could check for groups as well as permissions. I
don't know if this is as easy as it seems it might be or if it would
"add unnecessary complexity".
> - PermissionSystem maps (user | group) names to actions.
> - What's accomplished using IPermissionRequestor interface in software
> may be done using regular permissions and groups . I mean AFAIK both
> approaches shown below are *ALMOST* equivalent (CMIIW) :
>
> {{{
> #!python
>
> from trac.core import Component, implements
> from trac.perm import IPermissionRequestor
>
> class MyPermissions(Component):
> implements(IPermissionRequestor)
>
> def get_permission_actions(self):
> # AFAICR it sould be yield CMIIW
> # return ("MY_FIRST_PERM", "MY_SECOND_PERM", "MY_THIRD_PERM")
> yield ("MY_FIRST_PERM", "MY_SECOND_PERM", "MY_THIRD_PERM")
>
> }}}
>
> {{{
> #!sh
>
> $ trac-admin permission add dummy_group MY_SECOND_PERM
> $ trac-admin permission add dummy_group MY_THIRD_PERM
> $ trac-admin permission add real_group dummy_group
> $ trac-admin permission add real_user dummy_group
>
> }}}
As far as I can tell, trac-admin does not support defining new
permissions, although it might be nice if it did. When I try, I get
"MY_NEW_PERMISSION is not a valid action." Am I missing something?
- jevans
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac
Users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/trac-users?hl=en
-~----------~----~----~----~------~----~------~--~---
