Skip to end of metadata
Go to start of metadata

Introduction

Sometimes one wishes an issue to pass through a set of transitions, but the order in which they are run does not matter. For example, if an issue must be approved by 3 different managers, the order usually doesn't matter.

JIRA uses the OSWorkflow library to manage transitions. OSWorkflow is technically capable of handling our situation, through its mechanism of splits and joins. Although JIRA's workflow editor is not capable of adding splits and joins, they can be added by hand to the workflow definition, in XML form, and this modified workflow loaded back into JIRA.

This page describes how to implement a simple split where 3 managers are required to approve an issue before it can be worked on:

           /--> Manager1 Approves -\
          /                         \
(Create) -+---> Manager2 Approves ------> Open --> In Progress -> ...
          \                         /
           \--> Manager3 Approves  /

Try this at your own risk. JIRA does not 'know' about OSWorkflow splits and joins, and use of them will break parts of JIRA. Specifically:

  • Don't try to edit a splits-and-joins workflow in the workflow editor.
  • It is not possible to Bulk Transition an issue through a split/join workflow transition. Attempting to do so may break your issues. The workflow editor shows broken image icons for such transitions, so hopefully this is enough of a hint not to proceed.
  • Changing workflows appears to work, if the destination workflow defines a step for the "Pending Approval" status. However, it is a good idea to back up the database before changing workflows in production, as this may break in future.

Overall, you should only attempt to do this if you are happy to fix broken issues in the database if it all goes wrong. The relevant relations are described in the database schema documentation.

Create an interim template workflow

First, create a workflow that is as close as possible to what we want. You probably already have a workflow, and want to add an approval step at some point. For this example, we take the default JIRA workflow.

Add new statuses

We wish 3 managers to approve our issue. We need a "Pending Approval" state for issues being approved. Create two other temporary statuses too:

Create new workflow

Copy the workflow you wish to add approvals to. Call it "Interim Approval Workflow" or somesuch, since we will not actually be using it in this form.

Now edit the interim workflow. Add new approval steps, each linked to one of the new statuses. Also add a transition to each to the step you wish the approval to end with. In our case, we want approved issues to be Open.

You probably want each approval step to be restricted to a certain group, so add a Condition to each step to meet your requirements.

The end result of all this editing will look like this:

Edit the workflow XML.

Return to the page listing the workflows, and click 'XML' to get a copy of the interim workflow's XML. Save this to disk.

We now need to edit the workflow XML by hand, to:

  • Modify the transition that creates the issue, to split the issue into our 3 new steps.
  • Modify our 3 steps so that their "ManagerX Approves" transition invoke a join (undoing the split).
  • Modify our 3 steps to refer to the same status ("Pending Approval")

Adding a split

Open up the workflow XML in a text editor. At the end, before the closing </workflow> add the split definition:

Here we've defined a 'split' that results in 3 steps.

Now modify the transition where we want to invoke the split. In our case, we want to split immediately the issue is created, so we go to the 'initial' action, and change:

to:

ie. instead of resulting in step 1 ("Open") we result in split 1.

The step IDs in the join definition (7, 8, 9) should refer to the 3 steps we created:

The join is evaluated whenever an approval step is evaluated.

Adding a join

Similarly, add the join definition at the end of the file, before the </workflow>:

Again, make sure that the steps referenced (7, 8, 9) refer to the right steps.

We want this join to be invoked whenever a "ManagerX Approves" transition is run. So go to each approval step and modify the transition's unconditional result, eg. from:

to:

Note: we changed old-status to Finished, deleted the status attribute and replaced step="1" with join="1".

Do the same for Pending Manager2 Approval and Pending Manager3 Approval.

Make approval steps refer to same status.

We want all three approval steps (edited above) to refer to the Pending Approval state. Change:

to:

and:

to:

Import the edited XML

Now import the XML from the JIRA workflow editor. When importing, we've called it "Approval Workflow":

Clicking on it, it should look like this:

Apply new workflow

Now create a workflow scheme:

and associate it with a project.

Now try creating an issue. Immediately after creation, you should see 3 transitions available (depending on the conditions you placed on the steps):

Clicking on any 'Approve' transition will 'remove' it:

and after the last approval, the issue progresses to the 'Open' state:


Other Resources


  1. Nov 28, 2007

    Hi,

    how do I prevent a manager from approving more than once ?

    thx,

    Laurent

    1. Feb 04, 2008

      This would be done in the groups that have permissions for each of these worflows.  As long as you don't have someone in more than one of the approval groups, the manager should only be able to approve one time.

      That said, I've already had to clean up a few issues in the DB after a few months of usage, so the warnings are apt! 

  2. Mar 04, 2008

    How do I prevent someone from going in and editing the other fields after the issue has been approved?

  3. Aug 26, 2008

    Can a workflow be selected through a combination of two or more field values? For instance, I would like to use this for change management. Suppose my "project" is a particular application--let's call it Easyapp. Also suppose I wanted to have a different workflow for standard changes (e.g. two people approve before the change goes to "Open" state) as opposed to emergency changes (e.g. one person approves before the change goes to "Resolved" state). Based on the fact that "Issue Type" is the only other field that pops up on the "Create New Issue" screen, I imagine I would need to set up new issue types "Change - Standard" and "Change - Emergency." How can I set this up such that the *workflow* is different for a standard Easyapp change vs. an emergency Easyapp change, and how do I set it such that the workflow structure is the same for changes to another app but different individuals/groups fill the approver slots?

  4. Aug 05, 2009

    After being quite unhappy with previously posted solutions to handle multiple approvals, I've come up with a good solution using out-of-the-box functionality and the well supported JIRA Suite Utilities and Misc Workflow Extensions plugins.  I hope this helps someone else...

    2 parallel approvals (transitions) in a "Waiting for Approvals" step
    "Bus Approves"
    "Bus Rejects"
    "IT Approves"
    "IT Rejects"
    Transition condition shows only for appropriate user/s
    Transition goes right back to the same step "Waiting for Approvals", but sets a custom field (that doesn't show up on any screens) value

    A scheduled service jelly script runs each minute and automatically transitions any issues (that result from a saved filter of requests that have been approved by both IT and Bus) to a new "Approved" step.

    This method can be fully extended to handle all possible approval scenarios in my opinion.  Works great.

  5. Oct 21, 2009

    Is it possible to create a workflow where 3 out of 5 managers need to approve the ticket, instead of having all the managers approved the ticket (in any order)?  If so, I would appreciate any details into how this can be accomplished?

    thanks.

    1. Nov 23, 2009

      This can be accomplished through the general method of my previous post.

      - Have transitions that go to the same step, but set custom field values (Manager approvals)

      - Have a jelly script scheduled that automatically transitions any issues that match the criteria you want.

      I know this is very general, but hopefully that gets you down the right path...

      1. Jan 18, 2010

        Would it be possible post post a copy of your Jelly script to use an example?

  6. Aug 17, 2010

    Any idea on how to solve the "Could not load condition" when using the following code in Jira 4.1.x?

    I think the workflow library has failed to deal with beanshell.

    I tried to replace the condition with some regular condition using class type like :

    Split/Join works just fine.

    1. Oct 09, 2010

      Oh well, it has been long since the comment and I had been busy.

      After studying the workflow and plugin for a while, I fixed it myself by implementing the same logic as a custom workflow condition plugin.

      It works just like using class type condition.

      If anyone is interested, let me know.

      1. Oct 12, 2010

        I am having the exact same error  "Could not load condition", after upgrading to Confluence 4.1.2. Can you post the steps you took to resolve the issue?

        1. Oct 12, 2010

          Download

          jar
          source

          Installation

          copy the jar file into $JIRA_HOME/plugins/installed-plugins/ and restart Jira instance

          Configuration

          Modify the Workflow in xml format and replace the original beanshell condition with following code:


          • check.steps : Specify the forked steps you wish to check before joining (Please separate them using comma)
          • target.status : Specify the status to compare with forked steps you wish to check
          • class.name : Leave it untouched unless you modify the source package and recompiled your own

            Then update the workflow using the modified XML
          Limitation

          AND is the only logical operator implemented in this jar file.

          Warning

          For those issues that ran into "Could not load condition" error or has been created, you probably will have to delete them. The workflow migration will not be able to recover them for you.

  7. Aug 25, 2011

    Hi all,

    Did any one tried this workflow transitions successfully with Jira 4.3.3#617-r149616?

    I tried all of the above options and still getting "Could not load condition" error.

    Any help will be highly appreciable.

    Thanks,

    Raju