BRC Extranet's Purpose and Usage

• The BlackRockCity Extranet is a team-based coordination and collaboration tool, primarily intended to aid in the Burning Man Project's efforts to produce the annual Burning Man event in the Nevada desert.
• It is also intended to be the foundation for a more generalized groupware tool, one that could be used effectively by the greater Burning Man participant community, or by any other set of people requiring a workgroup-focused web collaboration tool.

Platform & Primary Dependencies

• FreeBSD 4.8-RELEASE
• Python 2.1.3
• Zope 2.5.1
• Plone 1.0.5
• ZPatterns-TransactionAgents 0.0.5 (including LoginManager)
• PostgreSQL 7.3.4

Significant customizations

• integration w/ multiple external databases (PostGreSQL, FileMaker)
• group awareness (hand-rolled)
• heavily customized member objects
• centrally managed group-aware security model
• changes to default workflow
• substantial UI changes (CSS and ZPT)

Significant customizations (cont'd)

• "TeamFolders"
  • primary user work area; the basic "unit" of the user interface
  • integral part of the group-aware security model solution
• strongly typed folders
  • more strict enforcement on allowed types
  • framework for easily customized "folder_contents" columns

A deeper look at how group awareness was implemented

• New roles have been defined at the root of the Plone installation: TeamMember, TeamEditor (i.e. TeamReviewer)
• User objects have been given teams_list and teams_editor_list attributes, data connections via ZPatterns
• Familiar Plone UI widgets have been modified to become context-sensitive

A deeper look at how group awareness was implemented (cont'd)

• When a user browses through TeamFolders, the user automatically gains TeamMember and/or TeamEditor local roles, as appropriate; this allows a centralized team security policy to be defined at the root of the Plone installation. This was accomplished by implementing a get_local_roles_for_userid() method in the TeamFolder class that overrides the default method inherited from OFS.Folder.Folder.

A deeper look at how group awareness was implemented (cont'd)

• Default workflow has been changed; new states are as follows:
  • private (visible/editable to Owners and (Team)Editors)
  • team (visible/editable to any member of TeamFolder's team)
  • public (visible to any extranet Member, editable by TeamMembers)
  • pending (same as public, but flagged for (Team)Editor review, to be considered for publishing to BRC)
  • BRC (centrally published, visible to any extranet Member, editable by TeamMembers)

A deeper look at how group awareness was implemented (cont'd)

• Additionally, team, public and BRC all also have a corresponding "locked" status, i.e. teamlocked, publiclocked, BRClocked. These states allow the same visibility as their unlocked namesakes, but edit privileges are only allowed to Owners and (Team)Editors.

Points of success

• specifications for the project have been met in a timely manner, and without going over budget
• initial aim of providing a central data repository and workspace has been accomplished
• TeamFolder structure of the UI has been well received by users and UE folks
• a tremendous amount has been learned by all involved

What would be done differently, if starting today?

• would not use ZPatterns
• would not use ZClasses
• would use GRUF
• would build more generally

Future Plans - The Good News

• removal of ZPatterns and ZClasses dependencies
• improvements to existing UI
• integration of additional features and products
• integration of more traditional CMS functionality into TeamFolders, to allow teams to maintain public facing sites from within their workspace

Future Plans - The Good News (cont'd)

• reimplement TeamFolder to automatically look for and interact with GRUF
• integrate team and team member management directly into TeamFolder UI