On Wed, Oct 28, 2009 at 9:28 AM, L Dary <[email protected]> wrote: > > Let me start by saying how impressed I am with TG2, and also how > excited I am to finally be starting to attempt to make some > applications with it (I started out reading the TG1 book, and really > watching the development, but never really made anything with TG1). > > I have decided to make my first attempt at a 'real' application, and > need some advice on where to start to figure out my first road block: > Authentication and Authorization. > > The way I am thinking about the users does not seem to fit into the > User, Group, Permission setup quite right. Let me describe the > structure I have put down on paper, and hopefully someone can help me > get started with a link or some advice. > > The application is based around self-contained instances of events. > Any user has the right to create their own events (which they are the > manager for). A user can be a participant in events, an assistant for > an event, a manager of an event, or they can also be a system > administrator. This breaks down really into two 'system-level' groups: > Users and System Admins. This seems like it would work fine with the > usual User, Group, Permission setup. > > It is the authorization of content, based on the user's specific role > within an event that has me stumped, however. A user may be part of > any number of events, and have different roles within each event. User > A might be the manager of Event A, and a participant in Event B. > > What I want to accomplish is that when User A requests details of > Event A that they would receive additional options than what they > receive when they request details of Event B. There is one additional > piece to all of this, which is that all participants in an event are > put into 'Teams' which further changes what is displayed on each page. > > The way I would describe it is: User, Group, Role (per event), Team > (per event), Permission.
You are certainly right and this is a flaw in the UGP paradigm as well as for r.what as that should be more generic. What you are describing is the abstraction of "row level permissions" or in a more general way. You need to know about the "owner of an object" In the last couple of weeks I have been discussion this with mcdonc (author of r.who, but not r.what) on IRC for the last few weeks and it is a hard topic to abstract. So far we came up with two alternative systems and well they are waiting for someone to sit down and write the code :) > I guess my overall question is: Can this be done with the existing TG2 > auth (or by extending it), or will I need to do something more > involved? > in theory yes, but that will involve some not-so-nice-hacks. You could create some sort of predicate that will pull things from the request and/or environ and create a SQL query to look for some particular field in your object. However this is very inefficient if you need to scale it. Ideally I think this should be develop as some sort of tgext module as it's an specific need. If you are interested in talking about it please drop by #turbogears on freenode. > Please ask for any clarification where I haven't been clear. > Thank you so much for any help. > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" 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?hl=en -~----------~----~----~----~------~----~------~--~---
