Grouper Developers Forum

[Jessica Bibbee <>]

MACE-Dir-Groups Conference Call

April 20, 2005

 

*Participants*

Tom Barton, U. Chicago (Chair)

Minh Nguyen -Stanford U.

John Ballem, Brown U.

RL "Bob" Morgan, U. Washington

Blair Christensen, U. Chicago

Gary Brown, U. Bristol

Steve Olshansky, Internet2

Jessica Bibbee, Internet2 (scribe)

 

New *Action Items*

[AI] {Minh} will send the first revision of the Subject API in CVS to the <grouper-dev> list by 29-Apr-05.

 

[AI] {Gary} will initiate discussion on the <grouper-dev> list regarding v0.6 UI support for custom group types and attributes, subject summary pages, and per-member links in group membership displays.

 

Carry-over *Action Items*

[AI] {Minh} will prepare integration questions related to Grouper, with the aim to present this information to the audience at the I2 Spring Member Meeting.

 

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

 

*Discussion*

The Group discussed features of the upcoming UI, as outlined by {Gary's} email: <

https://mail.internet2.edu/wws/arc/grouper-dev/2005-04/msg00017.html> 19-Apr-05. The first topic raised was search screens within Grouper – should the v0.6 release include only a simple search, or is it possible to offer an advanced search? – For those items not covered in this conference call, you can find discussion over the <grouper-dev> mailing list. [AI] {Gary} will initiate discussion on the <grouper-dev> list regarding v0.6 UI support for custom group types and attributes, subject summary pages, and per-member links in group membership displays.

To search for a subject type within Grouper, you enter a simple text display extension. How do we keep this straightforward for the user, and also differentiate between quick searching and a more sophisticated method to search people or groups? For the initial UI release of Grouper v0.6, should we focus primarily on providing a quick search only? The Group agreed that doing so would allow more time to refine a more advanced search – and meet the requirements in the API, while still providing some search capabilities upfront.

 

Currently, the search screen for groups is much clearer than is the search for people. We should place emphasis on keeping both interfaces equally clear and straightforward. How do we accomplish this, and what will the quick search look like? Is the API capable of supporting this? {Minh} explained that while the API is capable of supporting this, it is not currently capable of returning a list of attributes by which one can search. The idea is to provide a simple search, where one could select a number of attributes to search against. Which attributes would be most desirable by the user, and taking this into consideration, which attributes should we make available for a quick search? Is a search for groups and dates – including when it was created or modified – appropriate for a quick or advanced search? A few standard items include a text field, extension and display extension, also for stems. For example, you perform a stem search, then underneath that you search for a person, and so on. In addition, various attributes available to search against will be dependant upon the implementing site, and which attributes best fit their own strategy. After the initial release of the quick search, we may receive feedback from users that provides a more thorough coverage of their needs. This, in turn, could be outlined in a use case for future use.

 

Detailed discussion of whether components were simple or advanced included the "and" and "or" codes, or a combination of the two. How does this complicate the system? It may not present a challenge if there are only 20 groups represented, however the situation would look very different if 20 thousand groups are present. Perhaps such issues could be tackled as they arise, but we should anticipate a scenario and also a solution for it. The API does not have support for to "and" or "or" all the terms, but it could be done in the future.   For now, any spaces between text in the search field could be treated as one term, and this would be communicated to the end-user.

 

Ideally, capability of the Grouper management system should match the search needs of the users. Searching within a group should use the Grouper API. The subject API is a way to search for people for the purpose of adding them to a group. One essential item that should be supported is for the UI to report to the API who has authenticated, so that permissions can be enforced appropriately. As it cannot be done within Grouper, the information will have to go through an external storer – from an outside AuthN interface to the group member interface. The Group discussed how and what an agent interface is intended to support, which may be a subject for discussion at the upcoming BoF at the Spring 2005 I2 Member Meeting. For program details, see http://events.internet2.edu/2005/spring-mm/.

 

{Minh} will initially implement a database schema source pattern. It should have an internal repository so that it can be used immediately. A JWC connector would provide something for {Gary} to work with, and could be followed up with LDAP thereafter. This lead to the discussion of configuration methods – there will be a separate configuration file from Grouper, depending on if it is LDAP or JWC.

 

The tentative date for a freeze on the API will be 16-May-05, as {Blair} works to finalize the API support for the initial release of the UI in Grouper v0.6. [AI] {Minh} will send the first revision of the Subject API in CVS to the <grouper-dev> list by 29-Apr-05.

 

The next MACE-Dir-Groups conference call, schedule for May 4, 2005, has been cancelled due to an overlap with the Spring 2005 Internet2 Member Meeting. Therefore, the next scheduled MACE-Dir-Groups call will be on Wednesday, May 18, 2005 at 12pm ET.