Documentation reformatted as ReST and available at the top-level of the package.

Products/DCWorkflow/doc/actbox.stx

-
-Names and URLs for the actions box can be formatted using standard Python
-string formatting.  An example::
-
-  %(object_url)s/content_submit_form
-
-The string '%(object_url)s' will be replaced by the value of object_url.
-The following names are available:
-
-- portal_url
-
-- folder_url
-
-- object_url
-
-- user_id
-
-- count (Available in work lists only. Represents the number of items in
-  the work list.)
-
-The following names are also available, in case there is any use for them.
-They are not strings.
-
-- portal
-
-- folder
-
-- object
-
-- isAnonymous

Products/DCWorkflow/doc/basics.stx

-
-This product can be added to the portal_workflow tool of CMF site.
-It provides fully customizable workflow.
-
-To see an example, after installing DCWorkflow, using the "Contents"
-tab of your portal_workflow instance add a "CMF default workflow (rev 2)"
-instance.  The other way to create it is to add a "Workflow" object,
-selecting "dc_workflow" as the type.  The second way will create a
-blank workflow.
-
-This tool is easiest to use if you draw a state diagram first.  Your
-diagram should have:
-
-- States (bubbles)
-
-- Transitions (arrows)
-
-- Variables (both in states and transitions)
-
-Remember to consider all the states your content can be in.  Consider
-the actions users will perform to make the transitions between states.
-And consider not only who will be allowed to perform what functions,
-but also who will be *required* to perform certain functions.
-
-On the "States" tab, add a state with a simple ID for each state on
-your diagram.  On the "Transitions" tab, add a transition with a simple
-ID for each group of arrows that point to the same state and have
-similar characteristics.  Then for each state choose which transitions
-are allowed to leave that state.
-
-Variables are useful for keeping track of things that aren't very well
-represented as separate states, such as counters or information about
-the action that was last performed.  You can create variables that get
-stored alongside the workflow state and you can make those variables
-available in catalog searches.  Some variables, such as the review
-history, should not be stored at all.  Those variables are accessible
-through the getInfoFor() interface.
-
-Worklists are a way to make people aware of tasks they are required
-to perform.  Worklists are implemented as a catalog query that puts
-actions in the actions box when there is some task the user needs to
-perform.  Most of the time you just need to enter a state ID,
-a role name, and the information to put in the actions box.
-
-You can manage all of the actions a user can perform on an object by
-setting up permissions to be managed by the workflow.  Using the
-"Permissions" tab, select which permissions should be state-dependent.
-Then in each state, using the "permissions" tab, set up the
-role to permission mappings appropriate for that state.
-
-Finally, you can extend the workflow with scripts.  Scripts can be
-External Methods, Python Scripts, DTML methods, or any other callable
-Zope object.  They are accessible by name in expressions.  Scripts
-are invoked with a state_change object as the first argument; see
-expressions.stx.
-
-Once you've crafted your workflow, you hook it up with a content type
-by using the portal_workflow top-level "Workflows" tab.  Specify the
-workflow name in the target content type's box.

Products/DCWorkflow/doc/expressions.stx

-
-DCWorkflow Expressions
-
-  Expressions in DCWorkflow are TALES expressions.
-(See the <a href="http://zope.org/Documentation/Books/ZopeBook">Zope Book</a>
-for background on page templates and TALES.)
-Some of the contexts have slightly different meanings from what is provided
-for expressions in page templates.
-
-- 'here' -- The content object
-
-- 'container' -- The content object's container
-
-Several other contexts are also provided.
-
-- 'state_change' -- A special object containing info about the state change
-
-- 'transition' -- The transition object being executed
-
-- 'status' -- The former status
-
-- 'workflow' -- The workflow definition object
-
-- 'scripts' -- The scripts in the workflow definition object
-
-'state_change' objects provide the following attributes:
-
-- 'state_change.status' -- a mapping containing the workflow status.
-
-- 'state_change.object' -- the object being modified by workflow.
-
-- 'state_change.workflow' -- the workflow definition object.
-
-- 'state_change.transition' -- the transition object being executed.
-
-- 'state_change.old_state' -- the former state object.
-
-- 'state_change.new_state' -- the destination state object.
-
-- 'state_change.kwargs' -- the keyword arguments passed to the
-  doActionFor() method.
-
-- 'state_change.getHistory()' -- returns a copy of the object's workflow
-   history.
-
-- 'state_change.getPortal()' -- returns the root of the portal.
-
-- 'state_change.ObjectDeleted' and 'ObjectMoved' -- exceptions that
-  can be raised by scripts to indicate to the workflow that an object
-  has been moved or deleted.
-
-- 'state_change.getDateTime()' -- returns the DateTime of the transition.

Products/DCWorkflow/doc/howto.stx

-From: John Morton <jwm@plain.co.nz>
-
-Here's how I generally go about putting together a new workflow:
-
-1. Draw up a state diagram with the nodes as states and the arcs as
-   transitions. I usually do this on paper, then do a good copy in dia
-   or some other diagram tool, so I have an image to go with the
-   documentation. I usually spot several corner cases in the process.
-
-2. Start by creating an example DCworkflow, rather than a new one, as
-   it's faster to delete all the states and transitions than it is to
-   create all the standard review_state variables.
-
-3. In the permissions tab, select all the permissions that you want the
-   workflow to govern.
-
-4. Define any extra variables that you need.
-
-5. Set up the states for your workflow, one for each node in your state
-   diagram. Try to stick to the standard names for a publication
-   workflow, as some badly behaved products have states like 'published'
-   hardcoded into their searches (ie CalendarTool, last I looked). Set
-   up the permissions on the states now, as well. I find that using
-   acquisition for the site visible states, and using explicit
-   permissions for the private and interim states works well. Reviewer
-   roles should either have view permissions on every state or you
-   should change the appropriate skins to take them somewhere sensible
-   after a transition or they'll end up with an ugly access denied page
-   after sending some content back to private state.
-
-6. Set up any scripts that you'll need for transitions - pre and post
-   transition scripts and ones to handle complex guard conditions. Just
-   set up skeletons for now, if you haven't though through all the
-   details.
-
-7. Create your transitions from all the arcs on your state diagram. You
-   should be able to pick the right destination state as all your states
-   are already defined, and set up the right scripts to run, as you've
-   defined those as well. It's worth noting that the guards are or'ed -
-   if any guard matches, the transition can occur. You can specify more
-   than one permission, role or expression by separating them with a
-   semicolon.
-
-That about covers it. By working in this order, you tend to step through
-the creation process one tab at a time, rather than switching back and
-forth. I find it tends to be faster and less confusing that way.

Products/DCWorkflow/doc/worklists.stx

-
-Worklists are predefined catalog queries.
-
-When defining a variable match, you can enter a list of possible matches
-separated by semicolons. In addition, the matches will be formatted
-according to the rules described in "actbox.stx":actbox.stx.
-This way you can enter "%(user_id)s" to match only the current user.