Grouper Users - Open Discussion List

["GW Brown, Information Systems and Computing" <>]

This has been discussed before but I don't know that we got clear 
requirements. Given that the Subject API may be used in other systems - 
Signet at least that we know of - a Subject API solution would be better 
than a Grouper specific one.

The fundamental question must be: what rules governs who can see FERPA 
suppressed entries and where are they implemented? Should the rules, 
somehow, be built into the directory?

We have talked in the past of source adapters being 'aware' of who is doing 
lookups/searches so that the repository would be in a position to apply 
filters / make subjects anonymous.

Would we expect FERPA suppressed entries to appear at all - even 
anonymously - in member listings displayed for unprivileged users? The API 
would need to get something back in order to do membership calculations, 
but an API client could then suppress anonymous subjects.

I'm sure we can come up with a solution if we can flesh out the use cases.

Gary

--On 11 September 2008 17:13 -0500 Tom Zeller 
<>
 wrote:

> Perhaps we could mark subjects as hidden or invisible (based on attribute
> existence or value) so they are not displayed by the UI, e.g. in
> media.properties: subject.don't-display.attr=FERPA or
> subject.hide.attr=FERPA, subject.hide.value=true. Could be applied to a
> group (e.g. a course) subject to hide all members, or to particular
> subjects (e.g. a student who has requested FERPA). Maybe only applicable
> to specific privileges, e.g. not ADMIN.
>
>
> TomZ
>
>
> On Thu, Sep 11, 2008 at 3:56 PM, Chris Hyzer 
> <>
> wrote:
>
> I don't remember an open Jira issue about this.  It can sort of be done
> in 1.4 (coming out in Oct/Nov) with hooks.  You could configure your list
> or regex of folders (in grouper.properties or some config file) such that
> if a group is created under it (or edited if you like), that it will
> unassign the EveryEntity read or list privileges.  If there isn't a
> better way to do this (anyone?) we could consider a grouper-built-in hook
> like the group attribute validators... shouldn't be too difficult.
>
> I don't know of a way to add a "type" or some flag to folders, so a
> sysadmin would need to configure which stems or regexes are private.  If
> you did a regex (substring), then if your stem name has a certain
> substring then it would match, or maybe some certain substring in the
> description.  Another way to flag is making a 'marker' group with no
> members (e.g. called "school:etc:nonPublicRead"), and if that group has a
> privilege against a folder, it is "marked".  Doesn't sound ideal...  but
> just trying to think if it can be done without too large of a change
> (e.g. stem metadata)
>
> Thoughts?
> Chris
>
>
>
>
> > -----Original Message-----
> > From: Thomas M Goerger 
> > [mailto:]
> > Sent: Thursday, September 11, 2008 4:45 PM
> > To: 
> >
> > Cc: Kevin J ORourke
> > Subject: [grouper-users] FERPA Protected Data
> >
> > Hi,
> >
> > We're running into situations where we'd like to be able to restrict
> > the
> > ability for group members to see FERPA suppressed entries.  We've just
> > turned off the read attribute for now, but this is less than ideal, of
> > course.  I'm seeing from list archives that you might have been working
> > on
> > the ability to see a FERPA flag on a directory, and set suppression on
> > this entry according to this flag.  Has there been any progress on
> > this,
> > or if not, when might something like this be available?
> >
> > Thanks,
> >
> > ***********************************************************************
> > **********
> > * Tom Goerger                                  Email/Unix System
> > Administrator  *
> > *
> > *
> > * University of Minnesota                      Email:  
> >
> > *
> > * Operations, Infrastructure and Architecture  Phone:  4-5804
> > *
> > * Internet Services                            Office: 750 University
> > Park Plaza*
> > *
> > *
> > ***********************************************************************
> > **********



----------------------
GW Brown, Information Systems and Computing