[Trac] Re: Implementing a new permission (not associated with a specified component)
On Sat, Aug 8, 2009 at 8:47 PM, jevansjevans...@gmail.com wrote:
On Aug 5, 8:34 am, Olemis Lang ole...@gmail.com wrote:
On Tue, Aug 4, 2009 at 10:21 PM,jevansjevans...@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.
--
Regards,
Olemis.
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article:
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---
[Trac] Re: Implementing a new permission (not associated with a specified component)
On Aug 8, 6:47 pm, jevans jevans...@gmail.com wrote: 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? Assuming this can't be done, and I don't think it is possible, I was 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 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: Implementing a new permission (not associated with a specified component)
On Aug 5, 8:34 am, Olemis Lang ole...@gmail.com wrote:
On Tue, Aug 4, 2009 at 10:21 PM,jevansjevans...@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 Ollosry...@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.
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 trac-users@googlegroups.com
To unsubscribe from this group, send email to
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---
[Trac] Re: Implementing a new permission (not associated with a specified component)
On Tue, Aug 4, 2009 at 10:21 PM, jevansjevans...@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 Ollosry...@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
--
Regards,
Olemis.
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article:
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Trac
Users group.
To post to this group, send email to trac-users@googlegroups.com
To unsubscribe from this group, send email to
trac-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/trac-users?hl=en
-~--~~~~--~~--~--~---
[Trac] Re: Implementing a new permission (not associated with a specified component)
On Mon, Aug 3, 2009 at 6:21 PM, Ryan Ollosry...@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 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: --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: Implementing a new permission (not associated with a specified component)
On Aug 4, 7:18 am, Olemis Lang ole...@gmail.com wrote: On Mon, Aug 3, 2009 at 6:21 PM, Ryan Ollosry...@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 reading about the Tracpermissionsscheme [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-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. 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: you need to implement a custom permission handler: 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 (#39;MY_FIRST_PERM#39;, #39;MY_SECOND_PERM#39;) /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. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: Implementing a new permission (not associated with a specified component)
On Aug 4, 7:27 am, yoheeb yoh...@gmail.com wrote: you need to implement a custom permission handler: Hi Yoheeb, Thank you for the excellent response. This would probably 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. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
[Trac] Re: Implementing a new permission (not associated with a specified component)
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 Ollosry...@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. 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 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Trac Users group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~--~~~~--~~--~--~---
