Grouper Developers Forum

[Tom Barton <>]

The following represents the consensus to-date of the working group 
about priorities for substantial functional enhancements to grouper, 
based primarily on discussion over two recent conference calls.

I'm asking for further input into the prioritization process. The 
priorities as detailed below will influence our work for the next while, 
absent alternative positions being formulated and supported by working 
group members.

Work items, each with a descriptive label and short characterization, 
are arranged into categories A, B, and C, with A being highest priority, 
B second, and C third.

I've also made up a "Z" list below to record a couple of other 
functional enhancements that have been aired during these discussions, 
and that presumably represent work of a smaller scale.

Tom

--

"A" List

A1. LDAP provisioning connector

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 
it), this is still the most requested capability missing from the toolkit.

A2. Web services interfaces for query, management

Likewise declared out of scope a while back, this is probably the second 
most requested capability 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?

A3. Notification of changes

"Notification" refers to 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 and enables near real-time provisioning. With 
addition of operational data (what Subject made this change when), we'd 
also have a pretty good producer of events for an audit history (see B4 
below).


"B" List

B1. Sorting of various lists in the UI

Various lists of subjects, groups, and stems appear in the UI. They need 
to be sorted.

B2. Support for namespace transition

The hierarchy of naming stems in a deployment will change over time. 
Although the XML Import/Export tool supports prune & graft, for large 
changes that could take a while, be disruptive. Ability to logically 
"move" or "copy" a group or a selection of groups from one naming stem 
to another would be superior.

B3. Aging and reactivation of groups & memberships

Provide a java interface supporting automated inactivation and 
reactivation of groups and memberships. Also provide a default 
implementation that possibly uses a simple stateful model for groups 
based on last-manage time. For memberships, a simple stateful model 
based on TTL may be sufficient. The set of state transitions in the 
default implementation should include "overrides" that immediately 
deactivate or reactivate a group or a membership.

B4. 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. 
It's possible that A3 above will provide much of the needed support, so 
B4 is a catch-all for everything else that would need to be done. We 
should also consider the strategy of developing an EDDY agent to send 
grouper events into an external infrastructure that supplies persistence 
and analysis services.


"C" List

C1. 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.


"Z" List

Z1. Multi-valued group attributes

Support their existence and maintenance in the API. Provide 
corresponding UI support, including an optional drop-down list of 
potential values.

Z2. Bulk membership upload

UI support for loading in a bunch of members to a given group, perhaps 
by pasting a bunch of identifiers for Subjects into a window, or loading 
a local file containing same.