Personal tools
You are here: Home Products iterate Documentation HowTos Working Copy Workflow Customization
Document Actions

Working Copy Workflow Customization

how to utilize iterate's lifecycle events for workflow customization.

Customizing Workflow

Author: Kapil Thangavelu
Version: $Revision:$
Copyright: ObjectRealms, LLC (c) Creative Commons Attribution-NonCommercial-ShareAlike 2.5 License

WC workflow can be manipulated via an event subscriber. as a result of the copy the workflow state of the working copy is reset to the default for the content type. in plone 2.5 an object or container attribute market can be utilized to signify a custom workflow for an instance or containment structure. in plone 2.5, a custom workflow is utilized by the default adapter to restrict availability of the checkout to only the owner. The same behavior can be had in plone 2.1, by installing cmfplaceful workflow.

This relies, on an important part of the customization abilities offered by iterate in addition to creating custom policy adapters, namely event based integration, there are two events published by iterate during the lifecycle of a content checkout, an event for checkout, and an event for checkin (not nesc. parallel as checkouts can be cancelled).

Example Scenario

We want content in the published state to allow for a user with the Owner role to checkout the document, the content cannot be checked in by the owner, it must be submitted for review and published by someone with the 'Reviewer' role, on publishing the content should be checked in.

we can do this by creating a custom of workflow to apply to checkout content.

Considerations

Its important to keep in mind that we can get the effect of this just by configuring workflow to not allow the owner the permission to checkin content in its default state and normal workflow, ie. this example is illustrative but not exhaustive or nesc. the easiest solution, but its a good illustration of doing more interesting things with adding additional policy to iterate using events.

a more illustrative use case, which is implemented as a consequence of this example scenario is applying a different workflow to checkouts of content then the normal workflow assigned to that content, wherin we can apply arbitrary business rules to govern checkouts.

also this example utilizes the cmfplacefulworkflow api, which is not to be taken as endorsement of that api, which is fairly ugly at best, but the process of putting in something better is beyond the scope of this tutorial.

Customization Process

assumptions

you should already have your custom workflow created, and installed in the workflow tool. as part of using the cmfplaceful workflow api, you should have created a custom workflow policy which will be used for content checkouts, and which maps content types to custom checkout workflows. typically just setting the default to your checkout workflow's id will suffice. to match the rest of the tutorial code, the custom workflow policy created should have an id of 'checkout_workflow_policy'

high level intro to cmfplacefulworkflow api

the cmfplacefulworkflow api consists of attaching a workflow policy config object on the content to point to the workflow policy within the cmfplacefulworkflow tool in the portal root. this workflow policy is a mapping of content types to portal_workflow tool workflows, that replaces the standard mapping of the portal_workflow tool wherever a workflow policy config object is available in the containment chain of a piece of content.

create an event adapter for checkout

the adapter will modify the checkout, and using the cmfplaceful workflow api will apply a custom workflow to content, taking care to preserve for checkin any custom workflow already in place on the content for use after the working copy is checked in by marking the customization in such a way that we can distinguish between existing workflow customization.

create an event adapter for checkin

the adapter will modify the checkin, to remove the custom workflow api, so that the normal content's workflow continues from this point.

code

What follows is an example of registering an event subscriber, to change the workflow for checkouts, as outlined above:

from Acquisition import aq_base
from Products.CMFPlacefulWorkflow.WorkflowPolicyConfig import WorkflowPolicyConfig
from Products.CMFPlacefulWorkflow.PlacefulWorkflowTool import WorkflowPolicyConfig_id

USE_WORKFLOW = "checkout_workflow_policy"

def checkout_workflow_subscriber( event, object ):
    existing_policy = getattr( aq_base( object ),WorkflowPolicyConfig_Id, None )
    if existing_policy is not None:
        object                  
    policy = WorkflowPolicyConfig(USE_WORKFLOW)
    policy.coci_created = True
    setattr( object, WorkflowPolicyConfig_id, policy )

def checkin_workflow_subscriber( event, object ):
    policy = getattr( aq_base(object), WorkflowPolicyConfig_id, None )
    if policy is None or not getattr( policy, 'coci_created', None):
        return
    delattr( policy, WorkflowPolicyConfig_id )
by Kapil Thangavelu last modified November 7, 2006 - 23:43

For any issues with the web site functionality, please file a ticket.

Please consult the policy on plone.org content if you want your content published on this site.

Servers and hosting by