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