Parent not getting resolved when all sub-tasks are resolved in some cases

Brent Webster
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
November 3, 2015

I've seen several questions and associated answers to this question with the most interesting responses under https://answers.atlassian.com/questions/726.

Using ScriptRunner 3.1.4 under JIRA 6.4.11, I was able to get the post function: https://jamieechlin.atlassian.net/wiki/display/GRV/Built-In+Scripts#Built-InScripts-Transitionparentwhenallsubtasksareresolved to work under some conditions.  First, this post function had to be the last post-function in the list.  As well the current user resolving the last subtask had to be the same as the parent's Assignee user.  i.e in the parent issue, the workflow conditions are such that only the Assignee or a user with a "Manager" project role can resolve the issue.  In this case, the subtask was resolved by a third user who was assigned the subtask but was not a manager or the same user as the parent's Assignee.  BTW, it would work if a "manager" resolved the subtask or it was the same user as the parent Assignee.

Any ideas?

3 answers

1 accepted

0 votes
Answer accepted
Brent Webster
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
November 9, 2015

I guess I'll have to answer my own question based on my finding to date.

The current implementation requires a two pronged approach to resolving a parent issue:

  1. Add a subtask post-function(must be last):  Transition parent when all subtasks are resolved
  2. In the parent issue’s “resolving” action/step, the following condition must be added/enabled:
    All
    sub-tasks must have one of the following statuses to allow parent issue transitions: Resolved
    which is selected by "Sub-Task Blocking Condition"

This solution uses the ScriptRunner scripting technology but it has it’s fallbacks.

  1. All the subtasks must use the same “resolving” step/action to put the subtask into a Resolved status.  i.e. It doesn’t matter that the subtask is Resolved but rather how it got Resolved.
  2. In the parent issue, if the “resolving” action/step has associated workflow validators, they must all pass or the parent issue will not get resolved.

There are other plugins to investigate like Misc Workflow extension, etc but I'm sure they will have some gotchas as well.

0 votes
andreas
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
November 21, 2016

There's now a very easy to configure way to transition parents and sub-tasks in sync using Automation for JIRA!

You can easily modify related issues (such as parents, stories, sub-tasks, epics, linked issues and even JQL) using our related issues action and condition:

(this example transitions sub-tasks to "In Progress", but you could easily change this to "Closed" as well and make it so that the parent is updated when a sub-task changes)

For more details see https://blog.codebarrel.io/synchronize-parent-and-sub-task-issues-with-automation-for-jira-bdcca6c9d453

0 votes
JamieA
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
November 10, 2015

You are right that this function respects the permissions/conditions for the parent workflow, and it executes as the user doing the subtask transition.

Perhaps it would be useful to be able to specify the user the parent transition happens as.

> There are other plugins to investigate like Misc Workflow extension, etc but I'm sure they will have some gotchas as well

I think it depends... previously this would have worked in ScriptRunner because it used a lower-level API than it does now. On balance, I think it's probably best to respect the permissions, but to allow executing as another user.

Also there is a note in the docs that the function may need to be large, although personally I have not found that.

Brent Webster
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
November 10, 2015

I concur. Most of these other cookie cutter plugins assume a fairly generic workflow but when functionality from multiple plugins or some complex programming using ScriptRunner is being used then I'm not sure of the outcome. Documentation can be a killer as well. It looks like I'll just stick with ScriptRunner functionality. I wrote my own post-function which takes into account my workflow process and it is working fine.

Suggest an answer

Log in or Sign up to answer