subject API free form search should be able to filter by status

Michael, Rahul,

Please let me know what requirements are not met by this suggestion:

1. The Grouper team can modify the LDAP and JDBC2 (not JDBC) subject sources in the following way.

If subject sources had this param:

<param>
<param-name>statusAttribute</param-name>
<param-value>
status
</param-value>
</param>
<param>
<param-name>inactiveStatusValue</param-name>
<param-value>
inactive
</param-value>
</param>
<param>
<param-name>defaultStatusExpression</param-name>
<param-value>
status!=inactive
</param-value>
</param>

Then an LDAP or JDBC2 source could take advantage of it where by default it would filter by not inactive (in LDAP, just wrap the filter in an & and add that expression). If something special is in the search input, E.g. status=all, status=active, status!=active, status=inactive, then it would take that into account. Note, if status is all, then no expression needs to be added to the query. So… maybe the UI could have a checkbox that says “include inactives” or something to make it easier for users… worst case it could just be javascript to add “status=inactive” or “status=all” to the input field.

As far as the composites or loader or whatever, let me copy a modified version of what I had below:

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

If you arent using the loader or you want a group of provisioned users or something, then make that group:

a. school:it:apps:googleApps:groups:provisionedUsers
b. school:it:apps:googleApps:groups:allUsers (which is a composite intersection of provisionedUsers and school:community:activePeople). Anyone is not in activePeople will not be in allUsers
c. If you want to know who is provisioned and not active, you could do a group: school:it:apps:googleApps:groups:provisionedUsersInactive which is a composite of provisionedUsers minus activePeople. You can always query for this if you need it infrequently, we have never needed this type of group at Penn

Anyways, then you don’t need the shadow groups when people move back and forth.

Thoughts?

Thanks,
Chris