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.
- 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 [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
-~----------~----~----~----~------~----~------~--~---
