From: | Andreas Pflug <pgadmin(at)pse-consulting(dot)de> |
---|---|
To: | Tom(dot)Zschockelt(at)flender(dot)com |
Cc: | pgadmin-support(at)postgresql(dot)org |
Subject: | Re: group role membership |
Date: | 2005-11-10 14:48:20 |
Message-ID: | 43735DB4.7060400@pse-consulting.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgadmin-support |
Tom(dot)Zschockelt(at)flender(dot)com wrote:
> Hi Andreas,
>
> well my first thought for this was :
>
> - to extend the property window of a grouprole by a new tab called
> 'members of this role'
> - in this new tab integrate a treectrl which contains all direct member
> (roles) and if an item is a role with sub-members go down to the next
> recursive level
>
> e.g.
>
> - / root <name-of-current-group>
> |
> | - loginrole1 ( without member )
> | - loginrole2 ( without member )
> | - loginrole3 ( with member )
> |
> | - loginrole4 (without member )
> | - grouprole_a ( with member )
> |
> | -- ...
>
>
> and so on
>
> From my point of view it'll not necessary ( or not a highpriority item )
> to modify the underlying data from within this "new tab".
This is possible for <=8.0 groups, and it's a common task to assign a
bunch of users to a new group/role, so I'm inclined not to agree.
>
> (An other solution could be a simple reporting solution to get a list of
> people who have access to a certain object.)
An additional "who has which rights on this object" dialog from context
menu?
Regards,
Andreas
From | Date | Subject | |
---|---|---|---|
Next Message | Tom.Zschockelt | 2005-11-10 14:59:03 | Re: group role membership |
Previous Message | Tom.Zschockelt | 2005-11-10 14:13:31 | Re: group role membership |