Jira Automation: transitioning linked issue upon version release

[Sandra Kinsella]

Hi,

I am trying to achieve the following:

Trigger: a version in projects A, B, C or D (Jira Software) is released

For: all issues that were fixed in this version

 - check: do they have linked issues, of the linktype "blocks" or "causes" that belong to project E (Jira Service Management)

- for the **linked issues** check:

    -- do they have the status "Pending",

    -- are all other linked issues of the type "blocked by" or "caused by" either "Done" or                "Closed"

Action: transition the linked issue in project E to "Waiting for support" and leave a comment

I can't find a way to combine the two "for" Conditions (i.e. for all the tickets in the version, but then for the linked Issues of those). It only gives me the option to create different branches with one "for" condition each Which obviously doesn't solve my problem.

I thought about combining two rules, but again not sure what to use to trigger the second rule.

Any ideas on how I can solve this?

Thanks!

[Christian · Accepted solution]

Hello Sandra

You are correct, in that you can't have nested For loops, which has caused me problems too in the past. Here would be how I would handle this.

• Create a custom field for issue in project E, something like a checkbox called "Blocked in other project"
• Run your first for loop as you have it here, and in it have the action of editing the field to check the box "Blocked in other project". you can specify to not send emails for this action if you are worried about spamming people with emails. 
• Run your second for loop, using a JQL expression to select all issues where "Blocked in other project" = True. You can then add your conditions and actions as you have described. 

This is how I would deal with it, but I'm sure other people will have ideas as well.

Best,

Christian 

[Sandra Kinsella]

Thanks Christian,

I was hoping to avoid adding another field. But I think you are right, it is the only option at the moment.

Best

Sandra

[Joseph Chung Yin · Accepted solution]

@Sandra Kinsella -

Welcome to the community.  In my opinion, due to the limitation for now.  you may want to conduct what @Christian suggested or using WF customization -

1) Where when an issue transitioned into a specific status, then utilize the automation rule to be triggered to process.

Hope this also gives you some ideas.

Best, Joseph Chung Yin

[Sandra Kinsella]

Hi Joseph Chung Yin

Thanks for the additional idea. This is how I have it set up at the moment - the blocked issues get transitioned, when all blocking issues have been resolved.

That means though, that the fix, albeit implemented, is not yet available for the client. So the ticket is in the waiting for support status for a while until the version is released.

I could add another status in the service desk workflow, like "in an upcoming release", but then I have the same problem, that I can't move the ticket automatically to "waiting for support" once the release has been published.

I could of course add another status in the dev-project and move the tickets into this new status (e.g. "released") once the version has been released. But that causes problems with other things like searching for past tickets etc.

As long as the nestling of For loops isn't possible there is just no ideal solution in my eyes. I shall check out whether there is already a feature request for this and vote for it.