Implementing a new permission (not associated with a specified component)
Ryan Ollos
I would like to implement a new permission called TRAC_VIEW that will
be assigned to every authenticated user in my system. I did some
reading about the Trac permissions scheme [1], but I don't see how
this can be done without writing a plug-in. Is there a location I can
simply define a new permission?
I'd like to use the permission to control the display of custom tabs
on the navigation bar. For example, when using the TracTab plug-in a
permission must be specified to control who sees the tab [2]. If the
permission is not specified, then TRAC_ADMIN priviledge is required to
view the button.
The problem I have is that I want all users to see the tab, but I have
multiple groups with non-overlapping permissions, 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,
[1] http://trac.edgewall.org/wiki/TracPermissions
[2] http://trac-hacks.org/ticket/5611
Thank you,
- Ryan
Olemis Lang
>
> Hello,
>
> I would like to implement a new permission called TRAC_VIEW that will
> be assigned to every authenticated user in my system.
All users (except `anonymous`) belong to `authenticated` group.
> I did some
> reading about the Trac permissions scheme [1], but I don't see how
> this can be done without writing a plug-in.
Perhaps it is something related to definitions ( jargon ?) :
Trac permission : Represents an action (abstract, may be a group of )
that may be performed by users (e.g. TICKET_VIEW - view tickets and
comments, WIKI_VIEW - view wiki pages, ...)
User Group : A group of users having that may perform the same group
of actions .
> Is there a location I can
> simply define a new permission?
>
> The problem I have is that I want all users to see the tab, but I have
> multiple groups with non-overlapping permissions, 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 similar
permissions . That could be done using LDAP (for example, AFAICR there
are other group providers)
--
Regards,
Olemis.
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article:
yoheeb
> On Mon, Aug 3, 2009 at 6:21 PM, Ryan Ollos<ry...@physiosonics.com> wrote:
>
> > Hello,
>
> > I would like to implement a new permission called TRAC_VIEW that will
> > be assigned to every authenticated user in my system.
>
> All users (except `anonymous`) belong to `authenticated` group.
>
> > I did some
>
> Perhaps it is something related to definitions ( jargon ?) :
>
> Trac permission : Represents an action (abstract, may be a group of )
> that may be performed by users (e.g. TICKET_VIEW - view tickets and
> comments, WIKI_VIEW - view wiki pages, ...)
>
> User Group : A group of users having that may perform the same group
> of actions .
>
> > Is there a location I can
> > simply define a new permission?
>
> > The problem I have is that I want all users to see the tab, but I have
> > of those users access to resources I'd prefer them to not see,
>
>
> --
> Regards,
>
> Olemis.
>
> Blog ES:http://simelo-es.blogspot.com/
> Blog EN:http://simelo-en.blogspot.com/
>
> Featured article:
I know the archive seems lost, but I found this on the gmane copy. I
can't find the original poster though, credit is not mine, I just hit
CTRL-C CTRL-V:
<pre>
from trac.core import Component, implements
from trac.perm import IPermissionRequestor
class MyPermissions(Component):
implements(IPermissionRequestor)
def get_permission_actions(self):
return ('MY_FIRST_PERM', 'MY_SECOND_PERM')
</pre>
with MY_FIRST_PERM, MY_SECOND_PERM as some new permissions added in
this case
you then added the MyPermissions handler to your permission handler
list in config.
So, you put this file in plugins directory, then add (in this case)
MyPermissions to your permission handler configuration list.
Now, this assumes all you want is a new permission name. If you want
to do something special, you have to actually code it.
Although, just having the permissions is sufficient. Such as
IS_QA_PERSON then requiring IS_QA_PERSON with the worflow to move a
ticket from inQA->Verfied or some other special states.
RJOllos
> you need to implement a custom permission handler:
make a good entry for the Trac recipes page.
Olemis, thank you also for your response. I think we had a bit of a
disconnect there in terms of what I was actually asking for, but I
appreciate the effort.
jevans
On Aug 4, 9:27 am, yoheeb <yoh...@gmail.com> wrote:
> On Aug 4, 7:18 am, Olemis Lang <ole...@gmail.com> wrote:
> > On Mon, Aug 3, 2009 at 6:21 PM, Ryan Ollos<ry...@physiosonics.com> 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.
>
whatever they do could/would accept group names as well as actual
permissions. Ryan's is a perfect example, he already has a group -
'authenticated' - that he wants to be able to see the added tab but he
ends up needing to add another plug-in to just create a custom
permission.
My thoughts,
- jevans
Olemis Lang
>
> On Aug 4, 9:27 am, yoheeb <yoh...@gmail.com> wrote:
>> On Aug 4, 7:18 am, Olemis Lang <ole...@gmail.com> wrote:
>> > On Mon, Aug 3, 2009 at 6:21 PM, Ryan Ollos<ry...@physiosonics.com> 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.
- 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
}}}
The only difference between the later and the former is ... guess what
... SEMANTICS. In the first case the plugin dev means that no matter
where Trac will be deployed, he wants to check for multiple perm names
at once and therefore he defines a «composite» perm name. OTOH in the
second case the Trac admin defines a special group (i.e. like a role)
for people who can perform a set of actions. Then (he | she) states
that in this particular environment real (users | goups) may assume
that role, and therefore should be able to perform the same set of
actions.
So IMO this is a -1 (but as I said before that's the most irrelevant -1 you've
ever seen ) considering that, in software (dev | engineering) a very
important practice is separation of concerns and Trac separates very
well (IMO) the administration part from the implementation part
> Ryan's is a perfect example, he already has a group -
> 'authenticated' - that he wants to be able to see the added tab but he
> ends up needing to add another plug-in to just create a custom
> permission.
IMO that's not necessary (CMIIW anyway). My suggestion in this case is
to and rely on permissions inheritance and do something like :
{{{
#!sh
$ trac-admin permission add tabs_group MY_SECOND_PERM
$ trac-admin permission add tabs_group MY_THIRD_PERM
$ trac-admin permission add real_group tabs_group
$ trac-admin permission add real_user tabs_group
}}}
You dont even need LDAP or SVN groups or complex plugins (I just
mentionned that before since admins like to have centralized configs,
for instance, for multiple envs ). DeafultPermissions system should be
enough to do that.
We have this very old spanish phrase that states :
{{{
El que no oye consejo no llega a viejo
}}}
So I hope my comments be much more valuable this time , but feel free
to do whatever you want (... that's the best part of FOSS :o).
PS: I hope that the spanish part wont have so much catastrophic impact
considering firstly my ignorance, and secondly all the other things
being said
jevans
On Aug 5, 8:34 am, Olemis Lang <ole...@gmail.com> wrote:
>
> > On Aug 4, 9:27 am, yoheeb <yoh...@gmail.com> wrote:
> >> On Aug 4, 7:18 am, Olemis Lang <ole...@gmail.com> wrote:
> >> > On Mon, Aug 3, 2009 at 6:21 PM, Ryan Ollos<ry...@physiosonics.com> 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.
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
>
> }}}
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
RJOllos
> 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?
thinking it would be ideal to add a component to the NavAddPlugin [1],
TracTabPlugin [2]. and/or MenusPlugin [3] that allows custom
permissions to be defined through trac.ini. I'm using all 3 of those
plugins, and would like to define a custom permission for items in the
navigation bar defined through all 3 components.
I haven't looked closely as to whether it would be practical to
implement that feature, but I hope to do that in the near future.
[1] http://trac-hacks.org/wiki/NavAddPlugin
[2] http://trac-hacks.org/wiki/TracTabPlugin
[3] http://trac-hacks.org/wiki/MenusPlugin
Olemis Lang
>
> On Aug 5, 8:34 am, Olemis Lang <ole...@gmail.com> wrote:
>> On Tue, Aug 4, 2009 at 10:21 PM,jevans<jevans...@gmail.com> wrote:
>>
>> > 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.
It seems so ...
> 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.
[...]
... since I was talking about what u'r mentionning above. As I already
said plugins only care about whether an action or something else (e.g.
render a tab in mainnav) can be done or not. That's what permissions
are for.
I dont think that mixin dev features with deployment features be a
good idea. IMO the right way to let a group of users perform certain
action(s) is that the admin add permissions ...
>> - 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
>>
>> }}}
>
like I mentionned before
> As far as I can tell, trac-admin does not support defining new
> permissions,
[...]
No u'r right
> When I try, I get
> "MY_NEW_PERMISSION is not a valid action." Am I missing something?
>
Obviously since that's an upper case string which referes to an action
name, which can only be added by plugins (because of the reasons I
mentionned before ;o) and therefore the right way to do it (IMO)
should be to use «dummy» groups representing roles.
What you can do for sure is to define a group and specify that a
second group will inherit permissions.