Re: CUG - Mailing list pgsql-novice
From | Nabil Sayegh |
---|---|
Subject | Re: CUG |
Date | |
Msg-id | 3A7DA4ED.6465D32F@sayegh.de Whole thread Raw |
In response to | Re: CUG (Francisco Reyes <fran@reyes.somos.net>) |
Responses |
Re: CUG
|
List | pgsql-novice |
Thanks for the quick responses ... Francisco Reyes wrote: > I thought you wanted something more complex. From what I understand you > could implement "levels". When you put a picture you indicate what level > the person needs. Actually it will be a content management system, so it should be abstract enough to adapt to the customer's needs. > A picture with level 0 can be seen by anybody. A picture with level 1 can > be seen by anyone with leve 1 and above.. Get it? Okay, this could be an option, perhaps it's best to implement several different mechanisms from which the customer may choose. > Another way which is more flexible, although a bit more complex, is to > allow someone to belong to different groups and to have each picture > allowable to more than one group. That's the state of affairs. Now I want to attach group girlfriend(s) to group friends so that if I add new pictures and give them the group friends my girl may see it, !!!without_explicitly_mentioning!!! So far so good, here the level scheme could work, but ... guest | friend / \ family colleague | / \ girlfriend team1 team2 Business stuff is confidential and must not be seen even by my family. It's like attaching the (unix-)group users to the group audio. > --picture table > --group table > --user table > --user_group > --Picture table > That should work for what you described with no problems (except if you > have more than one user on the girlfriend category, then you could > eventually have serious problems with this setup) <G> (Thats just a matter of time-management ;^) I would like to add another table group_group and this puzzles me because I would need to recurse. Perhaps It could be done transparent to the customer by adding triggers which automatically add a new user to all necessary groups via prototypes but it would be hard to manage if they decide to give/take away permissions from one group. I think I will try a plpgsql function which descends the group tree till NULL or success. But this would restrict me to postgresql ... Is plpgsql available for other DBs ? cu -- Nabil Sayegh GPG-Key available at http://www.sayegh.de (see http://www.gnupg.org for details)
pgsql-novice by date: