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.

I completely agree. Why would you want to remove functionality that was so useful.

Any chance on re-opening the issue?
JRA-45379 relates to this issue as well.

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.