Grouper Developers Forum

[Tom Barton <>]

<CCing the grouper-users list for this thread>

As you probably know, the default privileges of the ALL subject are 
configurable. As shipped, every group that is created defaults to 
permitting ALL to VIEW and READ the group. So your use case becomes more 
substantial if you will have some groups that are more restricted in 
their READership or VIEWership.

With grouper 1.0 as is, you can create a help desk group and assign it 
READ priv for any groups that are otherwise restricted. That will enable 
members of the help desk group to see all of the memberships of any subject.

Every subject is limited by grouper's security, including self. A person 
can see all of their memberships in groups for which they have READ 
priv. If a group is created with a restricted READership, and if you 
want group members to be able to see their own memberships in the group, 
you'll need to assign READ priv to the group itself.

I've indicated how you can deploy grouper to meet your need, but I can 
imagine it might be difficult to operate this way if there are many 
different group managers using restricted groups - there's no guarantee 
that they'll all follow the conventions above. Do you think that'll be 
your circumstance, and that you'd really need some capability to 
"override" the privilege assignments made by those with group management 
authority?

Tom

Joy Veronneau wrote:
> Hi,
>
> We had another meeting about Grouper yesterday and the Helpdesk people 
> were asking if they could have the capability to look at all groups and 
> also for all netids, what groups they are in.  They just want read, not 
> update capability, so I don't think the wheel group would work for 
> them.  I was wondering if there is a way to set them up for a "read all" 
> capability?
>
> One solution for the helpdesk might be to have the user sign in to 
> Grouper and look at what groups they are a member of - will this always 
> show the user all their groups?
>
> Thanks-
>
> Joy