Grouper Developers Forum

[Tom Barton <>]

Below is an annotated list of options for substantial functional 
enhancements to Grouper in some 1.1+ release. Let's clarify them and add 
or merge items to arrive at a proper expression of how we see the 
possibilities.

In a second, later, cycle we will identify front-runners and serialize 
those.

In no particular order, the potential design items are:

1. Aging of groups & memberships

Provide interface for automated removal of groups and enhancements for 
automated removal of memberships. Default implementation possibly uses a 
simple stateful deprovisioning model for groups based on last-manage 
time. Adding a TTL on memberships may be sufficient.

2. Sorting of various lists in the UI

Until now we've dodged the need to have sorted lists of subjects, 
groups, and stems in the UI. Time to settle how it'll get done.

3. History, audit

First gain clarity on the types of audit requirements to be supported, 
and whether their support should be enabled per group, per naming stem, 
or categorically. Then design the necessary internal infrastructure.

4. Notification, changes

'Notification' is code for the infrastructure needed for event-based 
provisioning, and changes are the atomic messages to be passed along 
that infrastructure. Change support avoids the need for a downstream 
process to compute some type of logical diff in order to reflect 
incremental changes. We could elect to record changes without 
notification, but the reverse probably has little value.

5. Provisioning connectors

Although formally declared out of scope for the core product (as a 
matter of limited project resources, an anticipated great need by 
campuses, and therefore a solution to the problem of who will pay for 
them), this is still the number one thing missing from the toolkit. 
First off, a rather configurable JNDI provisioner. Any other types on a 
short list?

6. Live interfaces for query, management

Likewise declared out of scope a while back, this is probably the number 
two thing missing from the toolkit. What subset of the API ought to be 
exposed through each of what set of endpoints expressed in which web 
services idiom, and how should requests to & responses from those 
endpoints be structured?

7. Symbolic links

Things change, and so will the naming stems in a deployment and the 
authorities they reflect. Although the XML import/export tool can be 
used to do the prune and graft operations needed to convert from an old 
to a new system of naming stems, it might be good to be able to leave 
some references behind to smooth the transition.

8. Persistent storage supporting UI personalization

The UI has "saved groups" and "saved subjects" to make certain 
management operations more efficient, or even possible. Maybe persist 
these across UI sessions.

Interconnections among these include:

* aging & history/audit: aging might encompass history, and how we age 
might make various audit requirements easier or harder.

* history/audit & notification/changes: is history a log of (or a table 
of) notifications? Are changes needed to describe the "what" that 
happened when?

* notification/changes & provisioning connectors: provisioning 
connectors will need to take up whatever slack is left in the 
notification and change infrastructure.

Tom