Grouper Developers Forum

[Jessica Bibbee <>]

MACE-Dir-Groups Conference Call
January 26, 2005

*Participants*
Keith Hazelton, U. Wisconsin – Madison (stand-in chair)
John Ballem, Brown University
Blair Christensen, U. Chicago
Gary Brown, U. Bristol
Steve Olshansky, Internet2
Jessica Bibbee, Internet2 (scribe)

*Action Items*
[AI] {Gary} will look through existing Grouper documentation and offer
requirements and features to {Blair}; the two will work together to
propel this development.

[AI] {Blair} will continue to refine a true list of ins, outs,
features, and fixes for Grouper 0.5.1, 0.5.n, and 0.6, which he will
send out to the <grouper-dev> mailing list.

[AI] {Group} should continue to think about features found in or
missing from {Blair's} starter lists, passing any items to {Blair} and
the <grouper-dev> lists for review or addition.

*Discussion*
The Group discussed user selectibility options within Grouper. While
the ismember is an attribute put onto a person, the hasmember is a
member object that lives inside a group directory, such as LDAP. It
would be useful to have the ability to differentiate between immediate
only and effective only membership. How they are listed should be
clear within the UI. How will they appear if you browse within groups
for members? What limitations exist for listing membership? It might
be useful if you were able to pull down a group tree that listed who
was an immediate member; you could look at the group hierarchy. What
we really need are real-life use cases to more clearly define what
people would like to see coming from Grouper.

The hasmember may have less motivation from real world. The ismember
would display the subject and show the groups. There exists a way to
do this within Grouper, but it may be an item to consider putting into
the API, if it is not already there. It would provide what is needed
in the provisioning; in this way, people can look at it independently.
However, if that is a good feature within the API, it does not
necessarily become an automatic candidate for the UI – though it might
be a future consideration.

We should make sure that whichever route is chosen, it is not overly
complicated for the end-users. The Group should continue to think of
possible use cases to help define the application of memberships
within context.

If you do a subject search, where you list members of a group -are you
able to find out enough information about the user? Are you able to
trouble-shoot the authentication to determine why this person has
access? Given the API support, it is probably best to allow people to
browse, using a getattributes type of option. There are ways to find
out about the type information if you do not already know - for
example, in the tables. Currently, the assumption is made that there
will be one type; if multiple types come back, then it affects how the
UI works. When you create the group types, you also force the user to
create the appropriate group.

{Blair} walked the Group through his collected list of fixes and
enhancements for Grouper 0.5.1, 0.5.n, and 0.6. Discussion covered
topics including, but are not limited to: Java Beans compliance,
Grouper stem class, GrouperGroup loadByID() and loadByKey(),Initial
cleanup of internal, backend methods, Refactoring of test suite,
addition of new tests, Make sessions serializable,
GrouperAccess.has(), Improved compatibility with Oracle, MySQL and
other versions of HSQLDB, browse capabilities, Support for displayName
and displayExtension, etc. Grouper 0.6 will refine and improve
existing features. [AI] {Gary} will look through existing Grouper
documentation and offer requirements and features to {Blair}; the two
will work together to propel this development. [AI] {Blair} will
continue to refine a true list of ins, outs, features, and fixes for
Grouper 0.5.1, 0.5.n, and 0.6, which he will send out to the
<grouper-dev> mailing list.

The next MACE-Dir-Groups call will take place on Wednesday, February
9, 2005 at 12pm ET.