Workflow

You can export and import workflows and their settings this import step. The syntax is rather complex and verbose, so we recommend you to create and adjust the workflow settings manually, export them from the portal_setup tool as described in Using GenericSetup Efficiently and editing the resulting XML later.

You can declare and bind/unbind content-types to a certain workflow chain in the workflow.xml file. For example, the following snippet would register a workflow named my_workflow, set it as the default one, and unbind the My Type content-type from any workflow (including the default one):

<?xml version="1.0"?>
<object name="portal_workflow" meta_type="Plone Workflow Tool">
 <object name="my_workflow" meta_type="Workflow"/>
 <bindings>
  <default>
   <bound-workflow workflow_id="my_workflow" />
  </default>
  <type type_id="My Type" />
 </bindings>
</object>

If you want to bind a particular content-type to a particular workflow, use the syntax:

<bindings>
...
  <type type_id="My Type">
    <bound-workflow workflow_id="my_workflow"/>
  </type>
...
</bindings>

Once you've declared a workflow, you need to define it. Inside a folder named workflows in your profile, add a folder matching the name of your declared workflow and then a definition.xml file inside it. In our example above, profiles/default/workflows/my_workflow/definition.xml.

An short and simple definition.xml file looks like:

<?xml version="1.0"?>
<dc-workflow workflow_id="myt_workflow"
             title="My Content"
             state_variable="review_state"
             initial_state="draft">


 <!-- Permissions being managed -->
 <permission>View</permission>


 <!-- Workflow states, available transitions and permissions mapping -->
 <state state_id="draft" title="Draft">
  <exit-transition transition_id="publish"/>
  <permission-map name="View" acquired="False">
   <permission-role>Editor</permission-role>
   <permission-role>Contributor</permission-role>
  </permission-map>
 </state>

 <state state_id="published" title="Published">
  <exit-transition transition_id="retract"/>
  <permission-map name="View" acquired="False">
   <permission-role>Anonymous</permission-role>
   <permission-role>Member</permission-role>
  </permission-map>
 </state>


 <!-- Transitions between states, including guard conditions -->
 <transition transition_id="publish"
             title="Contributor publishes"
             new_state="published" trigger="USER"
             before_script="" after_script="">
  <action url="%(content_url)s/content_status_
                    modify?workflow_action=publish"
          category="workflow">Publish</action>

  <guard>
   <guard-permission>Publish content</guard-permission>
  </guard>
 </transition>

 <transition transition_id="retract"
             title="Contributor retracts"
             new_state="draft" trigger="USER"
             before_script="" after_script="">
  <action url="%(content_url)s/content_status_
                    modify?workflow_action=retract"
          category="workflow">Retract</action>

  <guard>
   <guard-permission>Retract content</guard-permission>
  </guard>
 </transition>

</dc-workflow>

First, we define the permissions we're going to manage (View in this case).

Later, we define the different available states, together with their role mapping and available transitions.

Last, we define what each transition should perform. An user must have the indicated guard permission in the context to trigger the associated transition.