Skip to Content.
Sympa Menu

grouper-dev - priorities for substantial functional enhancements

Subject: Grouper Developers Forum

List archive

priorities for substantial functional enhancements

Chronological Thread 
  • From: Tom Barton <>
  • To: Grouper Dev <>
  • Subject: priorities for substantial functional enhancements
  • Date: Wed, 16 Aug 2006 13:57:32 -0500

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.



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

  • priorities for substantial functional enhancements, Tom Barton, 08/16/2006

Archive powered by MHonArc 2.6.16.

Top of Page