I am also facing the same issue in JIRA 8.8 in a workflow transition.

Apologies, I accidentally assigned this to myself. Sorry for any notification spam! 

This is still happening with my Jira 7.7.2 . I can test it in script console and its running fine but when you keep the script in post function then getting the same error as described in the ticket. Any clue on it. 

dmeyer Note that the bug still exists with Validators: if the parent or linked issue being transitioned automatically has a Validator that fails, the same exception will be triggered.

Thanks for the clarification.

I'm afraid I completely forgot to notify it here, but the issue was fixed late last year in JMWE for both Server and Cloud.

For the record, Transition Parent post-functions still work in JIRA Cloud with the Sub-Task Blocking Condition. You must place the Transition Parent post-function after the Index Issue post-function otherwise the parent condition cannot be met! If the Sub-Task hasn't had it's status indexed, the Parent condition is failing (as it should).

There's no issue here and I've been able to duplicate the auto-transition behavior in a current cloud instance.

Sean, Likewise, I can easily transition (globally) a parent to an updated status (for instance, from "Open" to "In Progress") when any of the children subtasks transition from "Open" to something now in work. I also, prior to the latest JIRA build, could globally transition a parent to "Done" based on the conditional that all child subtasks were done. That's the rub now. The conditional rule in the parent based upon the state of all the children subtasks no longer works. While I've read up on many blogs, I still don't grasp why this is the case. Yes, I understand this feature was made available through the JIRA Misc Workflow Extensions plugin, developed by a third party vendor, but it doesn't explain why this feature would be removed when it appears so many were relying on it.

For now.....I have removed the conditional and added a viewable transition on the parent so when all of the subtasks are in a Done status, a supporting team member can"Press Done" thus effectively babysitting the parent through its completion. Blah.

That's my two-cents and a half vent. Moving on.

Thanks David - that makes sense.

I've created a new bug (https://jira.atlassian.com/browse/JRA-45379) and linked it to this issue. I'm going to reopen a support request directly with Atlassian that I originally had open for this and link to the bug I have just created.

bedfordsean Actually, the fix in JMWE was only intended to avoid errors when the transition requested on the parent issue is not applicable to the parent issue's current state. The problem you are encountering is different: the transition you trigger on the parent issue is valid, it is just prevented by a Condition. In that case, JIRA 7 will indeed not only fail the transition (which is expected) but also rollback the entire transaction (which is a regression).

Here is what I suggest: you should raise a new issue with Atlassian support, adding my description and requested that Innovalog be added to the support issue. Although there is probably nothing much that can be done in JMWE itself, it will at least make Atlassian aware of the broader issue.

David

Ok, so for me, this approach does not work.

I am doing the following:

• I have a "stories" workflow which contains "Selected for Development", "In Progress", "Awaiting test", "Done" states and global transitions.
• I have a "tasks" workflow which contains "Selected for Development", "In progress", "Awaiting test", "Ready for Release" states.
• The "tasks" workflow has post functions in it's transitions to push through stories to "In progress" as soon as any sub-task of that story is "In Progress" or "Awaiting test". Likewise for pushing stories back in to "In progress" upon test failures, etc. These post function transition changes are using the names for the global transitions in the "stories" workflow.
• The "stories" workflow has sub-task blocking conditions on it's global transitions to prevent the story transitioning to an invalid state if further sub tasks are created (e.g. the story can't go from "In progress" to "Awaiting test" until all of it's sub-tasks are "Ready for release").

This set up was previously working before JIRA 7. It was also working fine /with/ JIRA 7 and groovy expressions. This flow is now broken. It seems that the intended fix as detailed in this ticket doesn't work. Has anyone managed to get this working successfully?

I third Joe's comment - this is exactly how we use our workflow too (and I think is a perfectly reasonable use case!)

The reason we do this is so that we have a product level "Stories" board, as well as sub-tasks of those stories which exist independently on a "Tasks" board. This set up allows developers to work on the tasks and have the stories automatically bubble through to completion.

I second Joe Moore's comment. Perfectly said.

That is... unfortunate. It makes the system require a lot more babysitting.

This is something that will not be possible on JIRA Cloud for now - it was not possible before the upgrade to JIRA 6.5/7 either.

However, JMWE might in the future include some features to keep tasks and sub-tasks, as well as Epics and User Stories in sync, without requiring Groovy. Stay tuned.

If Groovy-based conditions are on their way out, what is the "correct" way to handle automatic transitioning of parent issues based on the current state of all child issues? I'll give you the rundown of how we have our work flow set up:

If a child transitions to "To Do" status, one of two transitions will fire:

• If all children are now in "To Do" status, the parent will transition to "To Do"
• Otherwise, at least one child is in either "In Progress" or "Done" status, so the parent will transition to "In Progress"

If a child transitions to "Done" status, the parent will transition to "Done" status if all other children are in "Done" status.

All three transitions are global ("To Do", "In Progress", and "Done"), but "To Do" and "Done" both have conditions on them that require all children to be in the same state. This is what caused issue for us when the transaction change was initially implemented. Using Groovy conditions, I worked around it and thereby kept the transition from firing when the transition conditional is not met.

bedfordsean The post-functions will look for a transition with the specified name only amongst those applicable to the issue at the current status. Since you cannot have two transitions with the same name applicable to the same Status, there is no risk of overlap.

What happens in the case that multiple transitions exist in a JIRA instance with the same name? (Another team in our company has a set of transitions named the same as ours, with different condition/trigger events).

Will using a transition name iterate over all of the possible transitions that apply and only WARN if there is no transition with a matching name?

Happy to use a "more correct" fix if this will work as an approach!

Explaining the ..
*Workarounds: *

1. Make the Transition being triggered a Global Transition.
   • The transition being triggered may be on a different workflow because it is triggered for the parent issue.
   • Global Transition is a transition that could be triggered from any status
   • Side effects:
     a) The global transition will now appear on every status as a possible option
     b) Triggering the transition for the parent issue will always be possible, regardless of the Status the parent issue is at.
2. Remove the Post function that affects the parent.

@dmeyer I was meaning something more along the lines of what @bob.swift%40charter.net suggests - a KB article detailing under which conditions a transition will roll back and fail would be useful. This is a change in behaviour to what JIRA does in the situations where a transition post-function causes a failure somewhere further down the line. Whilst previously if the down-stream action failed, the transaction would not be rolled back, it now is. I agree this is probably more correct behaviour, but a KB article detailing this, perhaps in addition to common error messages you may expect to see if you have misconfigured a workflow, could be beneficial to a lot of people!

I think a KB item could be constructed in a generic way about what JIRA does under scenarios with transitions within transitions. There are various ways for customers to construct post functions using various 3rd party or custom built post functions that transition other issues. Given that JIRA changed its handling of some of these scenarios, Atlassian is most qualified to document exactly what scenarios there are and the JIRA behavior. Given the limited time 7.0 has been available and the fact a number of users have already run into this that some more documentation may be needed.

bedfordsean, these post-functions and validators are provided by the JIRA Misc Workflow Extensions plugin, which is developed and maintained by a third-party developer and currently bundled in JIRA Cloud instances. Since these functions aren't directly developed or supported by Atlassian, providing KB articles about how to configure workflows on Atlassian documentation could lead to confusion for customers. For the same reason mld_dev, I recommend you contact the developer or ask a question on Atlassian Answers.

Hello Dave Meyer,

I have to chime in as I am using the current JIRA OnDemand and had already, and successfully, been using the transition parent as follows (very similar to Joe Moore above): Using a parent "Global Transition" and a parent conditional that requires all sub-tasks to be either "Complete" or "Done" , when true, it transitions the parent to its "Done" state.

Now, I too am receiving the error message described above. The mentioned workaround, "Make the Transition the parent has to go through a Global transition." was already being used.
When I originally created the transition for the parent it was "Global". And each subtask workflow, respectively, post function (last line) is set to to "transition # will be triggered on the issues' parent issue.

So, it was working as designed and now it is not. Can you please advise?

Thanks for commenting Dave.

Understandable (and personally I agree that this should not be reopened as it sounds like the previously configured workflows were only working due to JIRA not fully rolling back failed transactions - definitely a bug in my book!).

Since it is still possible to create such a workflow using Groovy, as I have done above, is it worth raising a documentation/FAQ task to detail how one would go about creating such a workflow? At present, it's possible to still build a broken workflow as JIRA will allow you to create a parent transition with a sub task blocking status.

I don't think we will reopen this, since we do not believe this is a bug. If you have conditions on the parent issue that prevent it from being transitioned, we rollback the entire transaction. We absolutely understand that there are complex workflow configurations that can be affected by this change, but this was an intentional change to make JIRA's behavior more predictable and in-line with our documented API.

Dave Meyer
Product Manager, JIRA

@Alexandre Marcoux - Thank you for the groovy script. I don't get the error anymore.

I basicallty wanted for as soon as any subtask was moved out of the first column of the workflow (in my case "To Do") for the User Story to be moved to that following state. Nothing else.

In this case I'm saving a click to my developers.

Cheers,
Pedro

No problem - I'm sure it can be cleaned up with a bit of debugging, but since I'm in JIRA OnDemand, I can't see any logs for why the other approach was failing!

Glad it's working for you!

Sean, that worked brilliantly. Your conditional code was near identical to mine, but I didn't use the boolean variable, which, as you admit, looks odd, but apparently seems to be required to make it work! Thanks a bunch, mate!

We were using JIRA in exactly the same way as Joe describes - performing a transition from our sub-tasks, with the parent having a sub-task blocking condition to stop the transition in certain circumstances.

I have fixed this by doing two things:

• Making all of our transitions at the parent task level global (with pre-conditions to hide them from users)
• Adding some groovy to each of the sub-task transition calls. Examples of this groovy code are below.

Transition if and only if the parent tasks is in specified status:

{{
String parentStatus = parentIssueObject.getStatusObject().getName();
if (parentStatus.equalsIgnoreCase("Selected for Development") || parentStatus .equalsIgnoreCase("Awaiting Test"))

else

}}

Transition if and only if the sub-tasks of the parent of the current sub-task are in a certain status (I know the logic is a bit convoluted here, but for some reason, without the extra boolean variable, this wasn't working for me!):

{{
Collection subTasks = parentIssueObject.getSubTaskObjects();
boolean shouldPerformTransition = true;
subTasks.each {
String status = it.getStatusObject().getName();
if (!status.equalsIgnoreCase("Ready for Release") && !status.equalsIgnoreCase("Done"))

}
if (shouldPerformTransition)

else

}}

Our usage of this feature has a condition on the transition that requires all sub-tasks to match the transitioning state for the transition to occur. Using this, we set parent tasks/stories/whatever to automatically transition to "Done" if all of their sub-tasks are "Done" and "To Do" if all of their sub-tasks are "To Do." It seems like I could potentially use a Groovy expression to loop through all of the parent issue's sub-tasks to check for appropriate state (which could, in fact, be even more powerful if used correctly), but I'm having difficulty getting the Groovy expression to work correctly. Could someone possibly point me in the direction of the proper syntax for iterating over the parent issue's sub-tasks and checking their status?

Another work around that is better than removing the Post or adding a Global Transition is to 'add' a groovy expression as confitional to the transition like this :
if(parentIssue.get("status").getName() == "Open" || parentIssue.get("status").getName() == "Reopened")

else

After discussion with the developer and the JIRA team, we are closing this issue as Won't Fix. In JIRA 7, JIRA's behavior was changed to roll back a transaction (in this case, the subtask transition) when a sub-transaction throws an exception (in this case, the parent issue transition). We believe this is the correct behavior for JIRA.

Fundamentally, this issue is caused when JIRA is configured such that a parent issue is supposed to be transitioned with a subtask, but cannot actually be transitioned. This should be resolved by amending the transitions or post-functions, as described in the workarounds.

Dave Meyer
Product Manager, JIRA Platform