Grouper Developers Forum

[Jessica Bibbee <>]

MACE-Dir-Groups Conference Call
October 5, 2005

*Participants*
Tom Barton, U. Chicago (chair)
Blair Christensen, U. Chicago
Steve Barrett, U. Cornell
Joy Veronneau, U. Cornell
Gary Brown, U. Bristol
RL "Bob" Morgan, U. Washington
Ann West, EDUCAUSE/Internet2
Renee Frost, Internet2
Steve Olshansky, Internet2
Jessica Bibbee, Internet2 (scribe)

New *Action Items*
[AI] Tom will mail the {grouper-dev} list with ideas regarding Level I support for extending group types and fields.
[AI] {Gary and Tom} will work on a proposal for the management of effective privileges.

Carry-over *Action
Items*
[AI] {Gary} and
{Blair} will work offline to determine an agreeable solution for housing
libraries within Grouper. (7-Sep-05)
[AI] {Tom} will
develop a list of how to point to different backend databases. (7-Sep-05)

*Discussion*
Attendees at Fall 2005 Internet2 Member Meeting brought positive feedback to the Grouper/Signet BoF, as there seemed to be a real sense of the reality of Grouper, especially now as the UI is available. There were also a few good questions regarding Grouper's integration approach with multiple applications, etc. What are the provisioning connectors that Grouper will use? Another interesting point is that the people designing security architecture generally lack management interfaces; Grouper may prove to be a useful addition here. {Tom} is still interested in hearing user feedback about desired alternate functionality. What are other items that can be put into Grouper's work plan for the future?

{Steve Barrett and Joy} will provide feedback regarding the approach that Cornell U. will take regarding Grouper and web services – standard management approach. Fedora is one project that {Steve} is currently working on, and may lead to interesting follow-up in Grouper's direction.

{Tom} detailed the current (draft) task list for the upcoming Grouper v0.9:
There are a couple issues with managing performance optimization - effective membership performance profiling and overall performance profiling.

Work to be done on the API refactoring refers to both internal and external refactoring. The table is currently a bit awkward and needs general style & crud clean-up. Transactional atomicity refers to being able to combine multiple operations into a single transaction for adding membership and adjusting groups, etc. Updating could be done in an efficient manner.

What capabilities should special grouper-specific subjects have? The special subject is intended to enable the default – view or read privileges of a group. What are the exact capabilities for the following: ALL (or ANY?), GrouperSystem, "wheel" group.
           
Searching in grouper is currently unscoped, meaning you cannot search by stem. The goal is for Grouper to eventually include scoped searching.

While group math is not a part of Grouper's capabilities currently, you are able to work with subgroups. Initial group math design will wait for implementation in v1.0, but its complexity will require thought before v0.9 is made available, so as to reserve enough time to make necessary change to the API. Design, such as for nexus integration, will follow in that timeframe as well.

Gary} has updated his To-Do list, which can be viewed in depth at: <http://www.bris.ac.uk/ips-projects/portal/groupsmanager/projectdoc/future.html>. Custom group types and customized attribute have not been implemented yet, but are still in the plan. Currently, you may search for people first, and then view/edit those privileges assigned to that person. A customization of this would allow the flexibility of assigning privileges first, or entering people. Another consideration is rethinking what logging the UI could do to compliment the API. All items in the To-Do list will be addressed for v1.0. [AI] Tom will mail the {grouper-dev} list with ideas regarding Level I support for extending group types and fields. [AI] {Gary and Tom} will work on a proposal for the management of effective privileges.

Functional customizability will be of great interest, and how it will adapt to upgrades. The majority of the components in the UI can be overwritten or extended via the XML configuration file. People may take that basic level of the UI and build in the functionality they need. The documentation for the UI architecture is included; feedback is anticipated for other aspects, such as group type, etc.

{Steve} raised the idea of a standard interface, and how it is gaining interest at the Cornell to exist across all their applications. How do others feel about alternate ways? What is it that institutions want to customize? U. Bristol's customization is available in the QuickStart, such that you can view a few examples of what changes they made, and how it looks.

The next MACE-Directory-Groups call will be on Wednesday, October 19, 2005 at 12pm ET.