Thread: group role membership

group role membership

From
Tom.Zschockelt@flender.com
Date:
Hi,

with postgres 8.1 and pgadmin 1.4.0 I found no way ( except a select on 
pg_catalog-tables ) to
get a list of all members belonging to certain group role.

The other way around works ( all assigned roles to a certain role).

If we use group roles to manage access to objects it would be neccessary 
to get a list of all
login-roles that are able to do e.g. a select .

It would be nice if an solution will step through all recursive level ( 
e.g. if a login-role is member of a group-role which is member of a 
group-role itself, ... ).

Is there any solution out there ?

Thanks in advance

tom


Re: group role membership

From
Andreas Pflug
Date:
Tom.Zschockelt@flender.com wrote:
> Hi,
> 
> with postgres 8.1 and pgadmin 1.4.0 I found no way ( except a select on 
> pg_catalog-tables ) to
> get a list of all members belonging to certain group role.
> 
> The other way around works ( all assigned roles to a certain role).

This isn't implemented yet; it will require an additional tab "members".

> If we use group roles to manage access to objects it would be neccessary 
> to get a list of all
> login-roles that are able to do e.g. a select .
> 
> It would be nice if an solution will step through all recursive level ( 
> e.g. if a login-role is member of a group-role which is member of a 
> group-role itself, ... ).

Please make a proposal how this should look like concretely, and how it 
should be controlled (context menu on object, property or so?).

Regards,
Andreas


Re: group role membership

From
Tom.Zschockelt@flender.com
Date:
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 (
withmember )      |       | - 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".

(An other solution could be a simple reporting solution to get a list of 
people who have access to a certain object.)

regards

Tom





Andreas Pflug <pgadmin@pse-consulting.de>
10.11.2005 14:51
       An:     Tom.Zschockelt@flender.com       Kopie:  pgadmin-support@postgresql.org       Thema:  Re:
[pgadmin-support]group role membership
 


Tom.Zschockelt@flender.com wrote:
> Hi,
> 
> with postgres 8.1 and pgadmin 1.4.0 I found no way ( except a select on 
> pg_catalog-tables ) to
> get a list of all members belonging to certain group role.
> 
> The other way around works ( all assigned roles to a certain role).

This isn't implemented yet; it will require an additional tab "members".

> If we use group roles to manage access to objects it would be neccessary 

> to get a list of all
> login-roles that are able to do e.g. a select .
> 
> It would be nice if an solution will step through all recursive level ( 
> e.g. if a login-role is member of a group-role which is member of a 
> group-role itself, ... ).

Please make a proposal how this should look like concretely, and how it 
should be controlled (context menu on object, property or so?).

Regards,
Andreas






Re: group role membership

From
Andreas Pflug
Date:
Tom.Zschockelt@flender.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


Re: group role membership

From
Andreas Pflug
Date:
Tom.Zschockelt@flender.com wrote:
>>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.
> 
> 
> I don't understand this comment.
> Do you mean that you disagree in my appreciation that modifying the 
> underlying data will not 
> be a high priority aspect or did you disagree with my proposal with the 
> treectrl ?

I *do* want the "add roles to this role" feature, I'm not sure if this 
is viable with a treeCtrl (though desirable).

>>>(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?
> 
> 
> yes ( as an additional feature it will be very helpful )

Let's see when I find some time (or somebody else, hint-hint-hint!)

Regards,
Andreas


Re: group role membership

From
Tom.Zschockelt@flender.com
Date:
>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.

I don't understand this comment.
Do you mean that you disagree in my appreciation that modifying the 
underlying data will not 
be a high priority aspect or did you disagree with my proposal with the 
treectrl ?


>> 
>> (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?

yes ( as an additional feature it will be very helpful )


regards

tom