Subject: Grouper Developers Forum
- From: Joy Veronneau <>
- To: , Grouper Users <>
- Subject: Re: [grouper-dev] another use case
- Date: Tue, 25 Jul 2006 15:29:46 -0400
We talked about this some more today. It turns out that everyone agrees that there are some groups that we won't want even the helpdesk staff to be able to see.
From experimenting with version 1.0, it looks like:
- If a group does not have "read" and "view" privs, then a person can not see if they are a member of the group.
- If a group has "read" but no "view" privs, then people can see that they are a member of the group (regardless of their "read" or "view" privs for the group.)
So we are going to propose that we restrict the creation of groups without "read" privilege, so that people can see what groups they are a member of, except for a very few groups. The helpdesk will either be able to ask the user to sign into the Grouper UI and look at their groups, and/or we may write a utility for the helpdesk to be able to do that.
In any event, this is better than what we have now. Nobody can see what permits they have, and only very few people at the helpdesk can look at your permits. The helpdesk would also like to be able to see "...and 4 secret groups" or something like that at the end of the list.
On Jul 25, 2006, at 11:43 AM, GW Brown, Information Systems and Computing wrote:
--On 25 July 2006 09:03 -0500 Tom Barton
I've indicated how you can deploy grouper to meet your need, but I canIf the capability is required, it may be possible to customise the UI to achieve it. One way would be to:
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
1) Write and configure a Servlet filter, which acts after the LoginCheckFilter, and which replaces the default GrouperSession instance with one for GrouperSystem - assuming some authorisation test is passed i.e. membership of the helpdesk group.
2) Override any 'write' action in Struts-config.xml, with an action which says 'This function is not available'.
This would allow the user to browse any stems/groups. Using the Subject Search tab would allow them to check memberships / privileges for any subject.
The advantage of this approach is that it can be achieved without modifying the UI source. The disadvantage is that links would still be provided for 'write' operations. However, it would only take a little effort to 'enhance' the UI so that it would behave as if the user only had read privilege, but for every group.
GW Brown, Information Systems and Computing
- another use case, Joy Veronneau, 07/25/2006
Archive powered by MHonArc 2.6.16.