On sprint start, transition linked issues (Jira Automation)

[axl.verheul]

Hi,

I want to setup a very simple Jira automation.

• Trigger: sprint started
• Condition: every issue in the sprint that has a linked issue of type 'relates to'
• Action: transition linked issue (in other project) to PLANNED

I have tried multiple approaches but keep getting 'component incompatible' errors.

This is what I expect would work (but doesn't):

And this works, but as soon as I change manual trigger to sprint started, it stops working. I confirmed by sending myself an email that Lookup issues returns the same list of issues before branching off:

I cannot figure out why changing the trigger results in an incompatibility issue.

Any help would be much appreciated, thanks.

[Bill Sheboy · Accepted solution]

Hi @axl.verheul -- Welcome to the Atlassian Community!

That error message can be a bit confusing, and what it means is a rule step needs an issue and none is present.

For your rule triggered on Sprint Started, you want to access the issues in the sprint.  And so normally the rule would branch to the issues in the sprint.  But you also want to access the issue which are lined to those issues in the sprint, and branches cannot be nested.

One solution for this scenario could be:

• Using Lookup Issues with JQL, gather issues in the sprint which have issues with a link type of "relates to"

project = yourProject
 AND sprint IN openSprints()
 AND issueType IN (Injection, Bug, Story)
 AND issueLinkType = "relates to" ORDER BY Key ASC

• Create a variable, using list filtering to extract the linked issues from the lookup results: https://community.atlassian.com/t5/Automation-articles/Filtering-smart-value-lists/ba-p/1827588  Let's name that variable varRelatedIssues

{{#lookupIssues}}{{#issuelinks}}{{#if(equals(type.name,"Relates"))}}{{inwardIssue.key}}{{outwardIssue.key}},{{/}}{{/}}{{/}}

• Finally, use a branch on JQL, and cleaning up the variable to remove duplicates, and removing any issues from the lookup (which are currently in the sprint and happen to be cross-linked as "relates to")

key IN ( {{varRelatedIssues.substringBeforeLast(",").split(",").distinct.join(", ")}} )
 AND key NOT IN ( {{lookupIssues.key.join(", ")}} )

Kind regards,
Bill

[axl.verheul]

Hi Bill,

Thank you for your reply! I was only now able to work on it and test your suggestion.

I don't understand how to configure the last step.

1. The initial lookup works fine. I can send myself an email with all sprint issues (that's why I'm surprised by the component incompatibility error missing an input type, as my email action does recognise the input).
2. The 2nd lookup (with your code) also works.
3. I am not sure if the assignment of a smart variable works, because when I send myself an email for debugging purposes, the body is empty. But that could also have to do with how I iterate over the smart variable.
4. I am not sure how to branch off this? There is advanced branching (with another smart variable assignment) and branch rules / related issues.

^ I also tried (type.name,"relates to")

[Bill Sheboy]

The JQL expression in the last step I described would be used with a Branch on JQL as you wanted to transition those issues to the Planned status.

Is that what you still want?

[axl.verheul]

Hi Bill,

I'm a bit lost as to how to implement the smart values.

The closest I have gotten is this:

But looking at the audit log, it only works with 1 issue in the sprint. If multiple issues are present, the JQL query fails.

It also seems the Transition is not performed against the linked issue. I have double-checked the destination status and it is there. I also found the numeric ID (10051) but can only enter the name from the dropdown.

[Bill Sheboy]

Issues can be linked to ones other than "relates to".  And so reviewing what I posted earlier, you will note that is the reason for the extra step with the created variable: to extract the specific linked issues with that link type only.

Here is a complete rule with my earlier suggests.  I recommend testing it fully and pausing to understand how each piece works to help with maintenance / improvement in the future.

• trigger: sprint started in YTP board
• action: lookup issues with the JQL of

project = yourProject
 AND sprint IN openSprints()
 AND issueType IN (Injection, Bug, Story)
 AND issueLinkType = "relates to"
 ORDER BY Key ASC

• action: create variable
  • name: varRelatedIssues
  • smart value: 

{{#lookupIssues}}{{#issuelinks}}{{#if(equals(type.name,"Relates"))}}{{inwardIssue.key}}{{outwardIssue.key}},{{/}}{{/}}{{/}}

• branch on JQL, with this JQL to find the linked issues not in the current sprint:

key IN ( {{varRelatedIssues.substringBeforeLast(",").split(",").distinct.join(", ")}} )
 AND key NOT IN ( {{lookupIssues.key.join(", ")}} )

• action: transition issue

[axl.verheul]

Hi Bill,

Thanks you so much for your help. I followed your instructions step by step but it's not working. :(

I can confirm that the lookup works:

But when I try to create the smart variable and debug it by sending myself an email, I get an empty list:

So it seems that something is going wrong there. I would love to try and fiddle with it, but I am not sure how I can test and see what's happening.

[Bill Sheboy]

A variable is text and has no issues or objects, such as the attribute "key".  When trying to send that email, please just try {{varRelatedIssues}} by itself.

Please post an image of the audit log details showing the rule execution as that may help explain why the issues are not transitioning.

[axl.verheul]

Hi Bill,

I tried and this is the log:

I also tried setting up something simple with alternative code and get no output. Seems the main challenge is that you can't double branch... first for issues in Sprint, and then for each linked/related issue.

[Bill Sheboy]

I see four problems to fix in what you showed:

#1) Your rule's definition of the variable varRelateIssues is incorrect.  That may be seen in the audit log as there are no keys listed within the parentheses for the JQL. 

It should be this:

{{#lookupIssues}}{{#issuelinks}}{{#if(equals(type.name,"Relates"))}}{{inwardIssue.key}}{{outwardIssue.key}},{{/}}{{/}}{{/}}

Within the smart value for issuelinks, the name of the link type is just "Relates" and not "relates to" as you tried, so it had no matches.

#2) Once again, {{varRelatedIssues}} is text, and so this will not work and may be removed from your email:

{{#varRelatedIssues}}
{{key}}: {{fields.summary}}
{{/}}

#3) Your rule appears to be accessing issues in multiple projects, and so it must use  multiple-project in scope to "see" them.  Your Jira Site Admin will need to make that change in your rule details as it is an admin setting.

#4) In your email, I see you are trying to filter the lookup issues, on the project id of the linked issues.  That is not possible...

When an issue is loaded for lookup issues, it contains all of the fields for the loaded issue.  But it does not contain all of the linked issues' fields, and so the project id is not visible yet.  (This applies for the issuelinks, subtasks, and parent smart values.)  If automation did load all of the fields, you could imagine a scenario where one linked issue pulled in all of the data in Jira site!

This is another reason we were building dynamic JQL with {{varRelatedIssues}} so the other field data could be loaded.

[axl.verheul]

Oke thanks, I will try tomorrow and let you know!

[axl.verheul]

Hi Bill,

I got my first 'success' run, so very happy with that!

For testing I have added 4 issues with a link to the sprint. The problem is that only 1 is transitioned to Planned. I suspect the varRelatedIssues is not selecting all 4 of them.

See the audit log below. Do you have any idea what might be causing this?

[Bill Sheboy]

Making progress!

Please add a write to the audit log after the variable is created so you can check what it contains.

Also please post an image of your current, complete rule for context.  Thanks!

[axl.verheul]

As requested, the audit log and full automation setup:

So good thing is, it is selecting all the correct HELP issues.
I added a check to make sure it's still Active (and not already In Progress).

The problem seems that it's not iterating over all the varRelatedIssues. Because HELP-6598 would also not pass the IF-condition and this is not being reported in the audit log.

[Bill Sheboy]

Sorry, my mistake: I tried to simplify the dynamic JQL and left off the possibility the linked issues may be in no sprints (rather than just not in the open sprint).

Please update the dynamic JQL for the branch to use this one:

key IN ( {{varRelatedIssues.substringBeforeLast(",").split(",").distinct.join(", ")}} )
AND key NOT IN ( {{lookupIssues.key.join(", ")}} ) AND status = "Active"

I added the status check at the end so you may remove the condition, making the rule more efficient.

One more thing to check: in the branch, is the option selected to...

Only include issues that have changed since the last time this rule executed

If so, that may exclude some issues.

[axl.verheul]

Hi Bill,

You are a hero!

Sorry I didn't get back to you yet, but I tested your changes and everything is working perfectly. The team is very happy with. Thank you very much!!