Plone as Groupware

An analysis and case study of Burning Man's BlackRockCity Extranet, Rob Miller

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