Having a group with only one person becomes sort of a pain. The use case is like this. I have a group of managers, who all have access to the same set of 753 resources.
The only thing is, a few of them I don't trust with various parts of the 753 resources, but I dont want to put them in a special group because a)its a pain to create a special group with 751 resources for each special case, and B) I don't want the managers to know that I don't trust them, I want them to have the same title as the others, but not have access. I agree, creating a separate group for said users would work, but be costly from a management standpoint if I have 58 managers 12 of which I trust in completely different ways from the others. It's really a matter of scale. -chris On Apr 15, 9:37 am, "Florent Aide" <[EMAIL PROTECTED]> wrote: > you mean having a user --> permission resolution route instead of a > user --> group --> permission ? > > On Tue, Apr 15, 2008 at 5:28 PM, percious <[EMAIL PROTECTED]> wrote: > > > > Registration is not part of the authorization layer per see. I hope we > > > can convert easily the existing registration package to work on TG2, > > > this was one of the reasons I kept the tg1 identity model intact. > > > Florent, > > > Can you also provide a table of "overrides" which would allow you to > > add/remove a particular permission on a user-basis? > > > -chris --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears Trunk" 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/turbogears-trunk?hl=en -~----------~----~----~----~------~----~------~--~---
