Grouper Users - Open Discussion List

[Chris Hyzer <>]

 

>

> why would i want my users to see inactive people let alone add an inactive

> identity to a group?

>

 

Inactive users definitely need to show on the screen… If someone is looking at members of a group, and that group has a member who has recently become inactive, they need to see their name/description instead of just their institution ID (e.g. 12345678).  Or if someone is looking through audit history, so see who did something, or what was done to someone, you would want to see the name of the person and description.  I think there is a disconnect about what a subject source is.  It is just a repository of entities and a way to look them up, search for them, etc.  If there is a subject which is not used in grouper, and is no longer active, then it can be removed from a subject source.  If there are any references to that user in the grouper_members table and references to the grouper_members row, then it really should not be removed from the subject source.  Its like Atlassian, if you have an external user which is not findable anymore, Jira screens wont even display anymore.  If you want to remove a user from Jira, you remove them from groups which have authorizations, not remove the subject from the external subject source.  Basically the subject source should not be used for authorization, it is just a linking of subject id and name/description/netId.  I think it would be really useful to find a way to satisfy your requirements without taking inactives out of the subject source.

 

There are problems with “inactive”.  Different people have different definitions of when someone is “inactive”.  Also, even though there is not an active affiliation with your institution, people might need access to resources.  If someone is on long-term disability, are they active?  Someone who has been retired for 5 days?  Someone who is collecting a severance package?  Someone who was visiting your institution and went back to their home institution?  Will those people need access to any resources?  Might someone want to add them to a group or remove them from a group or see if they are in a group?

 

> 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?

>

> is there some way to say "show me all memberships/privs for a user at a point in

> time?  Could I then click restore-all or selectively restore?

>

 

Well, if you don’t do the USDU remove of the subject, then if the removed subject is added back to the active subject source, then all their previous assignments will be there.  But after that, you would have to go to point in time, which I don’t know of a friendly way to do this, but it would be a useful UI feature, or at least useful to document how to do this manually…

 

>

> 5.       You mentioned this is at the Group level.  So some groups have this method

> and some don’t?

>

> i have a use case for the group level, or we think it is at the group level, yes. 

> We want to have 2 groups:  1 - active Google Apps users.  2 - Former GA users. 

> If a user becomes suspended, they are no longer active and we would move them

> from the group 1 to group 2.  Group 2 would be defined to go against the same

> "physical" subject store but with different parameters to allow the subject

> store to see inactive users.  We want careful control over who (or what in the

> case of a group), gets to see inactive users.  I hope this helps.

>

 

So what you are saying is that the active subject would be removed from the active google apps users, and the newly created inactive subject will be added to the former GA users?

 

How we would do this at penn is:

 

1.       Identify the populations who have access to GA: e.g. students, faculty, staff, ad hoc  (note, students/faculty/staff are loaded by the grouper loader, so inactives wont be in there)

2.       Make a GA groups:

a.       school:it:apps:googleApps:groups:allUsers

b.      school:it:apps:googleApps:groups:adHoc

c.       Add groups to allUsers:      school:community:students, school:community:faculty, school:community:staff, school:it:apps:googleApps:groups:adHoc

3.       Then, if the ad hoc users need to be active, either add a rule that says if a user is not in school:community:activePeople then remove them, or do a composite group that requires activePeople to be in the overall adHoc group

 

So you wont have inactive people using google apps, but there is nothing that will remove users from other groups once they become inactive since there are other groups that do not want that.

 

The UI would need to be very clear when searching for subjects so average grouper end users know to click an extra button if looking for someone not directly affiliated with the institution.

 

Thanks,

Chris