COmanage Developers List

[Emily Eisbruch <>]

COmanage-Dev Call 31-Oct-08

 

**Attending**

Heather Flanagan, Stanford (chair)

Digant Kasundra, Stanford 

Scotty Logan, Stanford 

John Robertson, Stanford

Dave Donnelly, Stanford

Tom Barton, U. Chicago

Michael Gettes, MIT

RL “Bob” Morgan, U. Washington

Steve Olshansky, Internet2

Emily Eisbruch, Internet2 (scribe)

 

*New Action Items*

 

[AI] (Digant and Scotty) will ask OOI if Drupal -- instead of Alfresco -- is acceptable for content management.

 

*Carry Over Action Items*

 

[AI] (Scotty) will send out to the group a list of APIs for the Domestication Guide.

 

[AI] (Bob) will send links to the group on the invitation problem.

 

[AI] (Digant) will write up how to integrate with setup wizard for the Domestication Guide.

 

[AI] (Ken) will ping Frank Siebenlist from Argonne National Laboratory, who is interested in COmanage.

 

[AI] (Digant) will create COmanage video #2, when the improved Collabmin GUI is available. 

 

[AI] (Scotty and Digant) will redo COmanage video #1 to correct a few audio issues.   

**Discussion**

Heather reported that the Stanford COmanage folks recently edited/updated the task list.

https://spaces.internet2.edu/display/COmanage/Task+List+to+Beta

This task list on the wiki is synchronized with what is in JIRA. 

https://bugs.internet2.edu/jira/browse/CMG?report=com.atlassian.jira.plugin.system.project:openissues-panel

- Content Manager

No one at Stanford has experience with Alfresco content management system, and there is a requirement to have it in COmanage for OOI.

Michael stated that MIT has experience with Alfresco and has found it problematic. Drupal is considered a more reliable content management system.

[AI] (Digant and Scotty) will ask OOI if Drupal - instead of Alfresco - is acceptable for content management.

Michael reported that domestication of Drupal is not complete, but should be resolved in the future, when Drupal v6 gets the content access module. 

- Grouper Integration with COmanage

Scotty is working on Grouper integration with COmanage, and he will refer to the Newcastle information on PhP clients for Grouper Web Service:  

https://wiki.internet2.edu/confluence/display/GrouperWG/PHP+Clients+for+Grouper+Web+Service

- Privilege Management in COmanage

Is there a simple version of privilege management do we want in the COmanage beta release?  There was a suggestion to include some privilege management that is group based. 

It was noted that privilege management in COmanage would not be relevant for Confluence in any case. Confluence uses externally provisioned groups, but not externally provisioned privilege management data.

Most likely, Drupal does not deal with external permissions either. John will find out if there are LDAP modules for Drupal. 

The conclusion was that privilege management doesn’t need to be in the beta version of COmanage. At the start, it makes sense to use groups where possible and rely on applications to do more detailed privilege management. Whatever is added later should be tailored to what people want. Keep track of more difficult requirements that come in from any of the deployments.

- Defer Feature Allowing Changing Federations

It was agreed to defer, until after the beta release of COmanage, items involving the ability to remove or change federations, change metadata, etc. So for the beta version of COmanage, users would get the federation they set up at the initial installation.

Bob noted  -- for future consideration -- that there has been quite a bit of discussion in Shibboleth oriented federation circles about distributed meta data management. 

- Defer Status and Backup Items

There was a proposal to defer for after beta release the status and backup items on the COmanage dashboard. Everyone agreed.

Scotty noted there is a basic status indicator that shows what applications are running. 

- People Picker Discussion

Ken had a question, emailed earlier today, regarding how the "people picker" will get stocked with possibilities.

It was noted that the “people picker” is based on something that exists in Australia. However, there are different rules in Australia, where it’s possible to search across every university’s directory.   

TomB: The concept of a people picker won’t go away. Since we are not Australia, what belongs more properly in that space? How can we kick start the inviting problem?

There was sentiment that it doesn’t make sense to start with a big bucket.  The people picker and collection of contacts is out of scope for COmanage. It makes most sense to start with a simple invite system based on emails, and to wait for user suggestions before considering anything more fancy.

 

Next COmanage Call: 14-Nov-08 at 2pm ET.