CollaborationWithArchetypes

Collaboration Management with Archetypes A presentation prepared for the 2004 Plone conference in Vienna, Austria. The Use Case: Burning Man - Annual construction of a temporary city (peak population: 35,000) in the Nevada desert - Major construction projects: - The Man - The Temple - Hundreds of others - Emphasis on community and inclusion - And, of course: - Fire - Fire - And more fire The Use Case: Burning Man - Team-centric, volunteer driven organization - Many teams, decentralized management - Teams require collaborative workspace(s) - Members apply for teams, are only approved after review - Team managers need to track team-specific information for each team member The Solution: TeamSpaces

- Archetypes-based team and team member management - Depends on CMFMember

- Introduces several new object types: - TeamTool

- Team - TeamMembership

- TeamSpace

- TeamRoster

The Types: TeamTool

- A containerish tool at the root of the Plone site - Manages allowed Team and TeamMembership

types - Manages default security policy for Teams and TeamSpaces

- Can contain only Team objects or instances of registered custom team types The Types: Team - Represents the logical entity of a team or workgroup - Lives exclusively within the TeamTool

- Is used for team member and team member data managment only; NOT used as a collaborative space for team content - Defines the security policy for itself and any related TeamSpaces

- Can contain only TeamMembership

objects or instances of registered custom team membership types - Can act as a schema provider for contained TeamMembership

objects The Types: TeamMembership

- Related via AT references to specific Member objects - Gets schema from Team object, can be used to store Team-specific information that is related to the Member Team security policy: TeamSecurity

- Team security policy defines allowed roles, default roles, and "active" TeamMembership

workflow states - allowed roles: the set of roles that the TeamSecurity

policy is allowed to manage - default roles: the allowed roles that are associated with a new TeamMembership

by default - active workflow states: the review states of the TeamMembership

workflow which imply that the member is active (i.e. entitled to security priveleges) on a given team - TeamSecurity

is a mix-in class; any class that includes this among its base classes will be able to support team security The Types: TeamSpace

- A content collaboration area for one or more teams - Implements the security policy for any related teams - Does NOT support any team member or member data management; that is handled entirely by Team objects The Types: TeamRoster

- A view-only interface component for listing the members of a team and related member data - Can live inside or outside of a TeamSpace

Customization Example: BRC Extranet - Custom Member, Team, TeamSpace

, TeamRoster

classes - Custom roster interface - ATContactInfo

- Custom roles, security policy, workflows, and portlets (currently being back-ported to ship w/ TeamSpace

product as a Plone Customization Policy) Resources: - TeamSpace

product page:

- CMFMember

product page:

- Samplex tutorial product:

- BRC ViewCVS

:

Acknowledgements: - Geoff Davis - Ben Saller and Kapil Thangavelu of ObjectRealms

- Jodok Batlogg of Telesis - Blue Dynamics - Alan, Alex, and the entire Plone Team