Grouper Users - Open Discussion List

[Chris Hyzer <>]

That was a design decision…

 

If you add a group’s members to your group while you have read access, then that group “has” those members, and can always query for them if you can list the outer group’s memberships.  However, if you remove that group from your group, then you wont be able to re-add it without READ of the underlying group.

 

So… if you are removing READ from a group, and you want to make sure no one is using that list, you should check to see where that group is a member of another group or a composite factor…

 

We did discuss this on a design call, but this exact issue didn’t make it into the Jira issue, I added a comment.

 

https://bugs.internet2.edu/jira/browse/GRP-199

 

OK?

 

Thanks,

Chris

 

From: Paul Gazda [mailto:]
Sent: Wednesday, April 08, 2009 2:55 PM
To: Grouper Users Mailing List
Subject: [grouper-users] Access privileges within sub-groups and composite groups

 

I am seeing what seems to be an inconsistency in the way Grouper handles access privileges in sub-groups and composite groups. I have looked in the listserv archives and wiki and could not find info on this. I see the same behavior in both cases and will explain it with a sub-group example.

 

I have a group A.

I have a group B.

I make group B a sub-group of group A.

 

I query for the members of group A using getMembersWs of GrouperClient 1.4.1 as a non-admin. I see all of Group A’s members plus Group B plus Group B’s members - as expected.

 

I remove read and view access privileges on Group B for GrouperAll.

 

I query for the members of Group B and get an error that the group is not found – as expected.

 

I query for the members of Group A and see all of Group A’s members plus Group B plus Group B’s members. That is not what I would expect. I would expect to see only Group A’s members because Group B should still be invisible to GrouperAll.

 

Paul Gazda