Grouper Developers Forum

[Jessica Bibbee <>]

MACE-Dir-Groups Conference Call
June 1, 2005

*Participants*
Tom Barton, U. Chicago (Chair)
Blair Christensen, U. Chicago

RL "Bob" Morgan, U. Washington

Shelley Henderson, USC

Brendan Belina, USC

Ido Carmi, USC

Gary Brown, U. Bristol

Ann West, EDUCAUSE/Internet2
Renee Frost, Internet2

Steve Olshansky, Internet2
Jessica Bibbee, Internet2 (scribe)

New *Action Items*

[AI] {Blair} will work on the modification of access to naming privileges within the API, regarding management of immediate membership privileges versus read-only effective membership privileges.

 

Carry-over *Action Items*

[AI] {Gary}, {Blair}, {Minh}, and {Tom} will coordinate efforts after the call to prioritize and minimize the list of fixes for the initial UI release of Grouper v0.6. (18-May-05)

 

 [AI] {Blair} will send signatures of the new methods to the {grouper-dev} list, which will appear in the transition between v0.5.1 and v0.6. (4-May-05)

 

*Discussion* 

The Group discussed the incorporation of subject API into Grouper API & UI. How is the model for group and subjects managed within the API? What information is in the tables – how many fields, and what are the identifiers, i.e. nameID subscription and attributes? Which information should Grouper Store?

 

The subject ID is the external ID, and the internal ID is hidden – not exposed in the API.

 

[AI] {Blair} will work on the modification of access to naming privileges within the API, regarding management of immediate membership privileges versus read-only effective membership privileges.

 

Grouper uses the subject API only when passing the subject to give memberships. The initial implementation should have the attributes working, though referencing the attributes has not yet been implemented.

 

Currently, memberships or privileges of user subjects can be edited from the member object. Ideally, you would be able to expand the list, such that you can view all the groups that a particular subject is in. This presents some complications, and brings up an issue of presentation and manageability within the UI. It would be efficient to show the immediate memberships that lead to effective memberships, which could be listed on one page.

 

How can it be informative without showing everything – is it possible to hide the information? A summary page could display all changes for the immediate and effective memberships. If you needed more information than just the summary, there would be a way to browse into it in more detail.

 

Thought it might prove difficult for external management systems, Grouper should work towards having two privilege interfaces – naming and attribute – to return the immediate assignees to list the attributes.

 

Another issue is a requirement in the UI that allows you to change access. If you are not given appropriate information, how does one gain access privilege? A consideration is to use a flat privilege model to provide the capability to show the structure.  

 

What is the real value in showing all the changes? This leads to complications, as there needs to be an understandable approach for the user – first make sure that editing direct memberships and groups is straightforward and reliable. For the initial release, stick to the basics – a more advanced approach can follow, if necessary. The Grouper v0.6 will list immediate links to show effective memberships, and a privilege management query could be changed to return effective memberships. How are the differences between effective and immediate membership handled? For more information, view the list thread < https://mail.internet2.edu/wws/arc/grouper-dev/2005-05/msg00013.html>.

 

The next scheduled MACE-Dir-Groups call will be on Wednesday, June 15, 2005 at 12pm ET.