Grouper Users - Open Discussion List

[Peter DiCamillo <>]

We have both active and inactive subjects, but also eventually remove 
subjects from the subject source (LDAP). We have uses for including 
inactive subjects in some groups, and in Grouper we don't treat active 
and inactive subjects any differently. The information we display for a 
subject includes the status. When subjects are removed, they show up as 
unresolvable in the daily Grouper report, and when there are a 
significant number of those, we'll use gsh to delete them.

Peter

On 4/3/13 4:27 PM, Jim Fox wrote:
> We never remove subjects from the subject source.  We do mark some
> subjects as 'abandoned', which means that someone once had two ids
> and we found out they represented the same person and he or she
> had to pick and abandon the other.  Those abandoned subjects we
> don't present to searches or member lists.
>
> Whether or not someone is active or not (or even if that distinction
> has an exact meaning) has no effect on group membership. If we have
> a group that requires, say, active employee status we add a
> qualifier to the group that requires its members to also be in the
> 'employee' group.
>
> Jim
>
>
> On Wed, 3 Apr 2013, Chris Hyzer wrote:
>
> > Date: Wed, 3 Apr 2013 09:55:33 -0700
> > From: Chris Hyzer 
> > <>
> > To: Michael R. Gettes 
> > <>
> > Cc: Rahul Doshi 
> > <>,
> >     
> > ""
> >  
> > <>
> > Subject: RE: [grouper-users] multiple subject sources
> >
> >
> > Can you join the dev call next wed at noon to discuss this?  I think 
> > there is too much back and forth for email.  We can have an out of 
> > band call
> > in the meantime if your timeframe cant wait a week. 
> >
> >  
> >
> > In the meantime, if other grouper users have some experience with this 
> > type of design where subjectId/sourceId tuples become unresolvable when
> > inactive, please let us know on the list…  Penn has evolved to where 
> > we try to not let any subjects move out of the subject source.  
> > Unfortunately
> > I don’t remember the exact pain points, but it is something that I 
> > generally assume as a Grouper developer (that subjects with 
> > assignments are
> > resolvable)
> >
> >  
> >
> > Also, if you could think about what your exact requirements are, more 
> > information there would help.  i.e.
> >
> >  
> >
> > 1.       You don’t want users searchable on the UI if they are 
> > inactive unless the UI-users selects an “inactive” button.  If they 
> > search for a
> > netId which is inactive, then do they still have to hit the “inactive” 
> > button, or is it just for freeform searches “john smith”
> >
> > 2.       Is it a requirement that all 
> > memberships/permissions/privileges/whatever should be automatically 
> > unavailable right when the subject is
> > unrevolvable?  i.e. Should memberships/privileges from active subject 
> > be migrated to the inactive subject?
> >
> > 3.       I forget if the new member table columns take care of this, 
> > but if a subject is unresolvable, will the UI/WS show the 
> > name/description of
> > the subject on the screen (or WS) from the point in time that the 
> > member table was last provisioned, or will it just show the user’s netId?
> >
> > 4.       If the user was mistakenly marked as inactive, and they are 
> > reactivated, should all their old memberships/privileges reappear?  What
> > amount of time should elapse when things are permanent if any?
> >
> > 5.       You mentioned this is at the Group level.  So some groups 
> > have this method and some don’t?
> >
> > 6.       Other things?  J
> >
> >  
> >
> > Thanks,
> >
> > Chris
> >
> >  
> >
> >  
> >
> >  
> >
> >  
> >
> >  
> >
> > From: Michael R. Gettes 
> > [mailto:]
> > Sent: Wednesday, April 03, 2013 12:11 PM
> > To: Chris Hyzer
> > Cc: Rahul Doshi; 
> >
> > Subject: Re: [grouper-users] multiple subject sources
> >
> >  
> >
> > Chris,
> >
> >  
> >
> > thanks for your perspective on all this… i've been reading this email 
> > every day and i think i am now at a point where i can comment.
> >
> >  
> >
> > it isn't clear to me that the audit-ability is so critical.  audit 
> > will show when user X is no longer resolvable and we would want to 
> > remove the
> > unresolvable at regular intervals.  Then X would reappear, as a 
> > different user against a different source.  And thats okay too.  What 
> > you identify
> > as a problem - I'm not seeing as a problem.  So maybe you could be a 
> > little clearer and possibly whack me upside the head to help me 
> > understand
> > why this really would be a problem?  I agree messing with the 
> > grouper_members table isn't a good approach.
> >
> >  
> >
> > As for your approach at Penn regarding (ACTIVE)/(NOT_ACTIVE) - I don't 
> > think we are interested in pursuing this avenue.  We only want/need to
> > present active users to our group managers.  If we present more, it 
> > gets more complicated do to showing more possible subjects and therefore
> > mistakes will happen.  I guess this is one of those cases in Higher Ed 
> > where we are all similar, but not the same.
> >
> >  
> >
> > /mrg
> >
> >  
> >
> > On Mar 29, 2013, at 3:10 AM, Chris Hyzer 
> > <>
> >  wrote:
> >
> >
> >
> > I don’t think thre is a good way to do this at the moment…
> >
> >  
> >
> > I don’t think you want two subject sources where users move from one 
> > to the other, since the member table will consider them two different 
> > users…
> > the old one will be unresolvable by the id/source combination, or if 
> > you migrated, then it wouldn’t really be followable in the auditing 
> > and point
> > in time.  Know what I mean?  I guess you could edit the 
> > grouper_members table’s source_id for a person if they move from 
> > active to inactive or
> > visaversa, though I don’t really recommend this since it is internal 
> > to Grouper and Im not sure what could happen.
> >
> >  
> >
> > At Penn we solve this by having the active/inactive string in the 
> > description of the subject, which shows up on the search results, and 
> > which can
> > be searched for.
> >
> >  
> >
> > My listing is:
> >
> >  
> >
> > Michael Christopher Hyzer (mchyzer, 10021368) (active) Staff - Isc 
> > Administrative Systems Tools And Technologies – Application Architect 
> > (also:
> > Alumni)
> >
> >  
> >
> > An inactive person would display as:
> >
> >  
> >
> > John Smith (12345678) (NOT_ACTIVE) Student - Summer Session - No Major
> >
> >  
> >
> > When we search, we just show everyone, and the user can clearly see 
> > who is active or not.  If they only want active people, they can 
> > search for
> > “john smith (active)”.  Though would be nice if they don’t specify to 
> > have the subject source add a filter for (active) being the search 
> > string. 
> > We could do that, though there wouldn’t be an easy way for them to 
> > know that they need to enter “john smith not_active” to search the not 
> > active
> > people…  anyways, we haven’t really had a problem with people 
> > accidentally picking the wrong person… does just showing the active 
> > state work for
> > you?  J
> >
> >  
> >
> > Thanks,
> >
> > Chris
> >
> >  
> >
> >  
> >
> > From:  [mailto:] On 
> > Behalf Of Rahul Doshi
> > Sent: Wednesday, March 27, 2013 9:25 PM
> > To: 
> >
> > Subject: [grouper-users] multiple subject sources
> >
> >  
> >
> > We are planning to have two subject sources in our environment.  One 
> > that will have all the active users and other that will have suspended 
> > and
> > deleted users or inactive users.  We want to configure grouper so that 
> > by default it just searches active users subject source instead of all
> > subject sources.  Is it possible to do that using simple configuration 
> > or I would have to customize the JSP?  For certain groups like group 
> > of all
> > suspended users we want to specify default subject source to be of 
> > inactive users.  Can we specify the inactive users subject source at 
> > the group
> > level let's say at the time of group creation so the that add member 
> > automatically only searches for users in inactive users subject source
> > instead of first selecting inactive users subject source manually to 
> > limit the search.  If this is not already supported can it be 
> > considered as a
> > feature request?  Also I would welcome any suggestions on how to 
> > implement this.
> >
> > Thanks,
> > Rahul
> >
> >