Grouper Developers Forum

[Jessica Bibbee <>]

MACE-Dir-Groups Conference Call
November 2, 2005

*Participants*
Tom Barton, U. Chicago (chair)
Blair Christensen, U. Chicago
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] {Joy} volunteered to provide feedback on U. Cornell's use of style sheets and screens.

[AI] {Gary} will update the API to support functionality displayed in the screens.

Carry-over *Action Items*
[AI] {Bob} will make suggestions regarding use of XML formats for load/distribution. (5-Oct-05)

[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*
{Blair} is working on the API functionality, which should be completed by the end of next week (11-Nov). {Gary} can then review it for forgotten features, and reflect on what is good or bad, etc, - this may take a couple weeks to change what is necessary and get all to a functional state. For more details, visit the javadoc in CVS <http://middleware.internet2.edu/dir/groups/grouper/grouper-0.6/docs/javadoc/>. Custom group types may not be listed, but memberships management and privileges should be available at a basic level. Deleting/adding of groups will also be there. New items include the transportation support along with the ANY or ALL Subject, but most of the work will simply offer a new way of doing it. Searching may or may not be merged at this time, but it is definitely on the agenda. [AI] {Gary} will update the API to support functionality displayed in the screens.

All should be merged by Friday, November 11, leaving additional time for documentation, packaging, and code work to be finalized by the end of the first week of December (2 or 5). This timeline will be adjusted as necessary, but should serve as a goal.

{Gary} guided the Group through the storyboard that he has put together to illustrate his proposed handling of effective memberships and privileges in the UI: <http://portal.bris.ac.uk/grouper-ui-docs/effective/>. Navigation through the subject and group summary pages has been simplified by use of additional links that will take you to where you want to go, as opposed to having to backtrack through multiple screens; you can cancel out of the current screen and simply begin browsing. A stem summary page is not available currently, though may be available in the future. When viewing group memberships, there are now two links - one for privilege assignment and another for subject attributes. Where multiple listings of privileges are shown for a single person, these will be condensed to show a single link. In addition, options should not be included in the UI where the user cannot exercise the links; simplification of all views should leave only the applicable options.

What are the Groups feelings on terminology used? – Is it geared to a developer-level, which might not be comfortable for the typical users? Settling on terminology used should not be confused with the actual type of information/content that is displayed. Once the Group reaches consensus on the use of terminology, the labeling can be altered to reflect these changes.

Discussion also included the use of group summary page versus simply having a subject summary page, and whether or how this introduces complexity. Management of stems and relationships using have/read/etc. privileges should settle on satisfactory presentation and function. [AI] {Joy} volunteered to provide feedback on U. Cornell's use of style sheets and screens.

Are there instances where a person without administrator privileges would have reason to create groups? U. Bristol uses these kinds of groups when ad hoc groups are needed. Are there situations where students would want to create groups? U. Michigan students are allowed to make groups, with some monitoring involved to avoid problematic situations such as offensive names, etc. {Renee} suggested that one could expect reluctance if that option was not made available.

Two kinds of capabilities for the UI to encompass are: 1) being able to present or hide complexity based on user privileges, and 2) being able to determine which subsets are displayed for a given user, by way of attributes or site policy. Is there interest in a separate function that allows you to access your own personal name space, while also being able to manage which parts of the hierarchy you view? {Gary} expects this will be possible, showing different things according to criteria based on what is to be done for a generic task. This component will be added to Grouper v0.9 if possible, in hopes of getting feedback for the v1.0 release.

The next MACE-Dir Groups call will be held on Wednesday, November 16, 2005 at 12pm ET.