On Sat, Aug 8, 2009 at 8:47 PM, jevans<[email protected]> wrote:
>
> On Aug 5, 8:34 am, Olemis Lang <[email protected]> wrote:
>> On Tue, Aug 4, 2009 at 10:21 PM,jevans<[email protected]> 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 [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
-~----------~----~----~----~------~----~------~--~---
