Transition All Subtasks function

Added by Jeff Turner, last edited by Jeff Turner on Nov 21, 2007  (view change)

When a parent issue changes status (via a workflow transition), transition all its subtasks. For example, close all subtasks when closing a parent.

Name Transition Subtasks
Version 3.6, updated for 3.11
Author Jeff Turner
Source Subversion: svn checkout https://svn.atlassian.com/svn/public/atlassian/jira/jira-transitionsubtasks-plugin/
Download jira-transitionsubtasks-plugin-3.6-4.jar, jira-transitionsubtasks-plugin-3.11.jar

This plugin only works with JIRA 3.6 and above.

In some circumstances where one has issues and subtasks, the state of subtasks should be automatically updated when the parent issue state changes. For example, when a parent issue is "Rejected", one might want to "reject" all subtasks. Similarly with reopening. The Transition Subtasks workflow post-function achieves this.

Installation

  1. Download the jar or build the jar from source
  2. Add the jar to your JIRA WEB-INF/lib directory
  3. Restart JIRA. In the Administration -> Plugins page you should see a new "Transition Subtasks Plugin".

Configuration

  1. In JIRA, edit the relevant (parent issue) workflow, and locate the transition you wish to trigger subtask changes on. For instance, say we have a subtask workflow:

and we wish to trigger the "Approve" transition for every subtask when the parent issue is Approved. To do this we would add a Transition Subtasks post-function to the Approve transition in the parent workflow, and configure it to run transition 11 ("Reject" in the subtask workflow above):

Yielding:

Then when the parent issue is Approved (transition 721 in the parent workflow), all its subtasks will be approved (transition 11 in the child workflow) too.

Preventing users manually triggering some transitions

Sometimes a subtask workflow transition should only be made in conjunction with a parent transition. For instance, say we want to "reject" subtasks, but only when the parent issue is Rejected. How do we prevent end users Rejecting subtasks individually?

This can be done by adding a FlagCondition condition to the subtask's Reject transition. This condition is only true if the caller sets a certain "flag" property:

Then in the TransitionSubtasks function, we set the flag. This means only the TransitionSubtasks function can invoke that subtask transition:

Labels

workflow workflow Delete
plugin plugin Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.

Comments (12)

 

  1. Nov 16, 2006

    Kevin Kuenstler says:

    It would be awesome if this would work on subtask types that use the same workfl...

    It would be awesome if this would work on subtask types that use the same workflow as the parent task, but leave subtasks of a different type alone.

     As of now, if you have a subtask of a different type, that uses a different workflow, it gives an error "No workflow action w/ id #.... available for issue ....." Obviously, because that transition # doesnt exist in that subtask's workflow.

     Kevin

    1. May 03, 2007

      Alexander Levin says:

      deleted

      deleted

  2. Mar 01, 2007

    Alexander Levin says:

    It seems it doesn't work well in 3.7. Transition of subtasks occures, but the su...

    It seems it doesn't work well in 3.7. Transition of subtasks occures, but the subtasks become out of state for filters as if they were not reindexed.

    1. May 02, 2007

      Dmitry Taur says:

      Same happens to me in 3.6.5

      Same happens to me in 3.6.5

  3. May 02, 2007

    Alexander Levin says:

    I added a JAR working correctly with versions newer than 3.6.4.

    I added a JAR working correctly with versions newer than 3.6.4.

  4. May 02, 2007

    Dmitry Taur says:

    Cool. Could you please post you sources. I'm just curious what changes did you m...

    Cool.

    Could you please post you sources.

    I'm just curious what changes did you make.

    Thanks.

    1. May 03, 2007

      Alexander Levin says:

      Since 3.6.4 they stop indexing before executing post functions, though we need t...

      Since 3.6.4 they stop indexing before executing post functions, though we need to start it.

      private void transitionIssueVerified(MutableIssue subtask, String caller, String resolution, int action, String flag)
{
   WorkflowTransitionUtil workflowTransitionUtil = (WorkflowTransitionUtil) JiraUtils.loadComponent(WorkflowTransitionUtilImpl.class);
   workflowTransitionUtil.setAction(action);
   workflowTransitionUtil.setIssue(subtask);
   Map params = EasyMap.build(IssueFieldConstants.RESOLUTION, resolution);

   if (flag != null)
       params.put(flag, "true");
   workflowTransitionUtil.setParams(params);
   workflowTransitionUtil.addAdditionalInput(flag, "true");
   workflowTransitionUtil.setUsername(caller);

   ErrorCollection errorCollection = workflowTransitionUtil.validate();

   printAnyErrors(subtask, errorCollection);
        
   boolean indexingPreviouslyEnabled = ImportUtils.isIndexIssues();
   try {
     if (!indexingPreviouslyEnabled)
	 ImportUtils.setIndexIssues(true);
     workflowTransitionUtil.progress();
   }
   catch (InvalidActionException e) {
     log.error("Action "+action+" is not valid for subtask "+subtask.getKey());
   }
   catch (Exception e){
     log.error("An exception occurred during transitionIssueVerified", e);
   }
   finally {
     // If indexing was disabled then turn it off no matter what happened
     if (!indexingPreviouslyEnabled)
         ImportUtils.setIndexIssues(false);
   }

}


private void transitionIssue(MutableIssue issue, String caller, String resolution, int action, String flag)
{
  try {
    Workflow wf = ManagerFactory.getWorkflowManager().makeWorkflow( caller );
    WorkflowDescriptor wd = null;

    wd = ManagerFactory.getWorkflowManager().getWorkflow(issue).getDescriptor();

    HashMap inputs = new HashMap();
    inputs.put("pkey", issue.getProject().getString("key"));
		inputs.put("issue", issue);
		inputs.put("originalissueobject", issue);
		if (flag != null) inputs.put(flag, "true");
 
		int actionIds[] = wf.getAvailableActions(issue.getLong(
				"workflowId").longValue(), inputs);
		for (int i = 0; i < actionIds.length; i++ ) 
			if (action == actionIds[i]) {transitionIssueVerified(issue, caller, resolution, action, flag); break;}
				 
  } catch (Exception e) {
	log.error(e);
  }
}

      1. May 03, 2007

        Dmitry Taur says:

        Since 3.6.4 they stop indexing before executing post functions, though we need t...

        Since 3.6.4 they stop indexing before executing post functions, though we need to start it.

        Yeah, now I see.

        1. Nov 21, 2007

          Jeff Turner says:

          I've fixed this in Subversion, and in the 3.11 build.

          I've fixed this in Subversion, and in the 3.11 build.

  5. Jul 03, 2007

    Melvin Mah says:

    Let's say if I want to add this to one of my transitions, i am required to fill ...

    Let's say if I want to add this to one of my transitions, i am required to fill in two fields. Any examples of how to fill that in? The instructions to insert the parameters are quite confusing.

  6. Aug 21, 2007

    Ville Jyrkkä says:

    Is there plugin that checks subtasks statuses when a subtask is closed and then ...

    Is there plugin that checks subtasks statuses when a subtask is closed and then if all subtasks are closed then it closes the main issue? That would be helpful in certain situations.

  7. Sep 27, 2007

    mameha says:

    Can this be used to set a due date for all subtasks automatically?

    Can this be used to set a due date for all subtasks automatically?