Automation smartvalue with the status of a linked issue

[Christof Hurst]

Hi, 

following situation:

• In an automation in issue A i need the statusname of a linked issue
• There are potentially more link issues
• Correct issue is linked via type "Communication" and linktype is "is communication for"

Tasks: 

• Determine the correct linked issue
• Get the status of these

Problems:

• I struggle with the syntax
• This is my attempt which gets no result:

{{#issue.issuelinks.type}}
  {{#if(equals(name, "Communication"))}} 
    {{issue.issueLinks.inwardIssue.status.name}} 
  {{/}}
{{/}}

• A smaller try gave me the names of the two linktypes of the test issues

{{#issue.issuelinks.type}} 
  {{name}}
{{/}}

So can someone find my mistake?

BR Christof

[Christof Hurst · Accepted solution]

Maybe I have to go another way and lookup for the issue via JQL:

issue IN linkedIssues("{{issue.key}}") AND issueLinkType = "has communication"

[Bill Sheboy]

Hi @Christof Hurst 

With the linkedIssues() JQL function, you may include the link type inside the function: https://support.atlassian.com/jira-software-cloud/docs/jql-functions/#linkedIssues--

And for your original question, your syntax for the smart value, list filtering was incorrect for the issuelinks smart value.  When manually checking links with direction, the correct link name must be identified and the keys filtered.

For example, to filter for linked issues which block the current issue, this would return their key and status name.  I added spacing to make reading it easier.

{{#issue.issuelinks}}
  {{#if(and(equals(type.inward, "is blocked by"), 
            exists(inwardIssue.key)))}}
    {{inwardIssue.key}}: {{inwardIssue.status.name}}; 
  {{/}}
{{/}}

Kind regards,
Bill

[Christof Hurst]

Thanks a lot. That worked and is much more complex than I thought.

What do you think is the better way? Doing it with smart values like that or a lookup issue action and using that issue status?

BR Christof

[Bill Sheboy]

From a rule maintenance perspective, using the JQL will be easier for others reading your rule to understand.

From a performance perspective, the data is already loaded in the issuelinks smart value; using that approach saves a few seconds per rule execution over making another roundtrip to the database with the lookup.  You appear to be at a Premium license level and so that is likely less of a concern.

Understanding both methods helps in other rule scenarios which require using one or the other technique.

In my experience, I favor maintainability over performance until performance becomes a problem, so I would go with the JQL and lookup one.

[Vishal Biyani]

@Christof Hurst 

Can you try using below syntax to get linked issue key and its status name

{{#issue.issuelinks}} {{outwardIssue.key}} {{outwardIssue.status.name}} {{/}}

[Christof Hurst]

This gets nothing. With inward... it gets the other linked issue which is wrong.

[Pasam Venkateshwarrao]

Hi @Christof Hurst 

    We can get the value of issue key based on the type of 'issue links'. 

   When we link "Issue B" from "Issue A" using 'blocks' (Issue A > More > Link > Issue B),

• "Issue A" blocks "Issue B"
  
  • Inward Issue - There will not be any inward issue. As link originated from 'Issue A'.
  • Outward Issue - Outward issue is 'Issue B'. As link is created from 'Issue A'.
• "Issue B" is blocked by "Issue A"
  • Inward Issue - Inward issue is 'Issue A'. As link is created from 'Issue A'.
  • Outward Issue - There will not be any Outward issue. As link is from 'Issue A'.

• We can fetch the values of linked issue keys (both "Inward" and "Outward" using below smart values.

  Inward Issue is {{issue.issuelinks.inwardIssue}}
  
  Outward Issue is {{issue.issuelinks.outwardIssue}}
  
  
  

{{issue.issuelinks.inwardIssue.key.status}}

[Christof Hurst]

This is true but not related to the problem.

Issue A have one or more linked issues. Only ONE of these is relevant (Communication and inward linktype "is communication for") and status status of only this one needs to be determined.