[Zope-CMF] departmental hierarchies with modified workflow

[Jens Quade]

Jon Franz <jfranz@one.net> writes:

> Has anyone else implemented such a system? where did you begin, and what
> should I keep in mind?  I'd be glad to
> see how someone else solved similar problems, especially if it was in a
> simpler manner...

I'm currently implementing a simple system of "workgroups".
I've written some notes about it:


Portal Workgroups

 Abstract

  Workgroups divide a portal in several areas where different groups
  of reviewers do their work.  I want to describe how I designed and
  implemented "Workgroups".


 Why workgroups?

  In the default CMF, every reviewer can review everything.
  In the real world, a site may have a diversity
  of topics, and not everyone should be able or even asked to
  review everything. We moved the content objects from the
  user centric "Members" folders to "Workgroup" folders.

  It is also useful to have different sets of subjects in
  different areas of a site, at least to make the selection
  easier.


 WorkgroupFolder and portal_workgroup

  I decided to follow the example of the existing portal tools:
  I wrote a tool with a simple API for use by every other part
  of the portal that wants to know something about workgroups::

    def getWorkgroupIds(self):
        "get list of workgroup names in portal"

    def getWorkgroupOf(self,something):      
        "get workgroup of something"
  
    def getSubjects(self,wgid=''):        
        "get list of allowed subjects"
  
    def getLocalReviewers(self,wgid=''):
        "get list of local reviewers"

    def getReviewedWorkgroups(self,user):        


  The current implementation uses PortalFolders with two extra
  properties: WorkgroupName and SubjectList.  To get the workgroup
  name of an object, acquisiton is used.  Also, all workgroups are
  expected to be in the portal's root.
 
  To make the management of the special workgroup properties easier, I
  wrote WorkgroupFolder with a TTW management screen for the "local"
  subject list.

  Reviewers are managed by assigning the local role "Reviewer" to 
  selected users.

  The same API for workgroups could be implemented without folders,
  e.g. by collecting the who-reviewes-what information in the
  portal_workgroup tool and using every object's metadata to store the
  assigned workgroup of an object.


 The Workflow

  With DCWorkflow it was easy to make a single workflow work for
  all Workgroups simultaneously. The only drawback is that I have
  to create one worklist for each group of reviewers.

  - I added "workgroup" as a Workflow Variable
    (with expression getPortal().portal_workgroup.getWorkgroupOf(object))
    and to the catalog's list of indexed fields.

  - for each workgroup wg, I created a Worklist like this::

         Catalog matches: review_state = pending ;         
                          workgroup = wg
         Requires role:   Member , 
         expr:            getPortal().portal_membership.\
                             getAuthenticatedMember().getUserName() in\
                          getPortal().portal_workgroup.\
                             getLocalReviewers('wg')
  

 Different sets of subjects

  I inherited my own portal_metadata tool from MetadataTool and
  implemented this functionality in listAllowedSubjects, calling
  portal_workgroup if the content object is known and part of a
  workgroup.




-- 
                                                     http://www.jquade.de/