Grouper Users - Open Discussion List

["Michael R. Gettes" <>]

This is certainly where CMU is headed, but we just ain't there yet. In the 
meanwhile, I have to deal with accounts going inactive and current practice.

/mrg

On Apr 3, 2013, at 22:07, Tom Barton 
<>
 wrote:

> Similar to UDub, we also (almost) never remove subjects from the subject 
> source. The notion of placing an account in an "inactive" state, in order 
> to disable "all" access, that used to be the practice at UChicago was 
> superseded years ago as our access management practice improved. Accounts 
> can access pretty much exactly what we need them to access in all states - 
> we have effectively mitigated the risk of leaving accounts "active 
> forever". This has also helped us support a range of "micro use cases", in 
> which people that have disengaged from all formal affiliation with the 
> institution can continue to collaborate in some way with others that remain 
> here - the folks here can still assign privs to UChicago resources to their 
> departed colleagues, within their delegated authority.
> 
> Tom
> 
> On 4/3/2013 3: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
>>> 
>>> 
>>> 
>>> 
>>> 
>