nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Comment on linked issues (not the issues in the release) when a Version is Released

Tyler Monroe

I'm struggling to figure out if this is possible.

Here's the scenario: When a ticket comes into the service desk project, we link that ticket to another ticket in the actual engineering project where the work is executed (simply using the linked - "relates to" relationship).

Right now when we fix bugs related to those service desk issues in a release, someone has to go back to the service desk tickets and comment in them to the effect of "this was fixed in version xyz", so the service desk team knows they can close out the issue and/or let the customer know.

So I'm trying to build an automation that does the following:

When a version is released, look through all the tickets that are part of that release, then comment on any tickets LINKED to those (NOT comment on the tickets in the release itself). This feels like it should be simple, but I'm having trouble with the logic to make it happen.

Thanks in advance for any help you can provide.

Accepted answers

Bill Sheboy

Hi @Tyler Monroe -- Welcome to the Atlassian Community!

Which version of Jira are you using: Cloud, Server, or Data Center?

The different versions have different automation capabilities, so knowing the version will help to focus any suggestions.

For now, I will assume Jira Cloud or Data Center...

First, your rule will need to be multiple-project or global in scope because it is trying to access / edit issues in a different project. Your Jira Site Admin will need to help create such a rule (or change the scope of your rule).

Next, this would be easy to solve if automation rules supported nested branching, but they do not. And so a workaround is needed to get those linked issues: using Lookup Issues as a go-between.

action: lookup issues, use JQL to get the issues in the released version
branch on JQL: using the results of the lookup to find the service project's linked issues, based on the project and link types
- action: add your comment to the relevant issue

That branch on JQL may need to use dynamically-generated JQL from the lookup. For example...

project = yourServiceProject AND 
  (
    {{#lookupIssues}}
    issue IN linkedIssues({{key}}, "relates to") {{^last}} OR {{/}}
    {{/}}
  )

How that works...

assume the project of the needed issues is the service project
and iterate over the results of the lookup issues
adding JQL to find linked issues of the desired link type
finally, adding OR to separate the clauses for all except the last one found

Please check the link types / direction to confirm they match your needs.

Kind regards,
Bill

All comments

Bill Sheboy

Hi @Tyler Monroe -- Welcome to the Atlassian Community!

Which version of Jira are you using: Cloud, Server, or Data Center?

The different versions have different automation capabilities, so knowing the version will help to focus any suggestions.

For now, I will assume Jira Cloud or Data Center...

Next, this would be easy to solve if automation rules supported nested branching, but they do not. And so a workaround is needed to get those linked issues: using Lookup Issues as a go-between.

action: lookup issues, use JQL to get the issues in the released version
branch on JQL: using the results of the lookup to find the service project's linked issues, based on the project and link types
- action: add your comment to the relevant issue

That branch on JQL may need to use dynamically-generated JQL from the lookup. For example...

project = yourServiceProject AND 
  (
    {{#lookupIssues}}
    issue IN linkedIssues({{key}}, "relates to") {{^last}} OR {{/}}
    {{/}}
  )

How that works...

assume the project of the needed issues is the service project
and iterate over the results of the lookup issues
adding JQL to find linked issues of the desired link type
finally, adding OR to separate the clauses for all except the last one found

Please check the link types / direction to confirm they match your needs.

Kind regards,
Bill

Darryl Lee

Heya @Tyler Monroe yes, this definitely should be do-able, although... it'd be a lot easier with ScriptRunner JQL Functions, which would let you do something like:

project = SDP and issueFunction in linkedIssuesOf("project=CD and fixVersion={{version}}")

(Although argh, because of changes in Cloud I don't think this is possible :-{)

But since we probably can't do that, you'll need to do Advanced Branching. Luckily @John Funk and @Bill Sheboy already answered a similar question to this, which saves me some time:

Automation for Version Release Trigger

Let us know if that solves things for you!

Darryl Lee

Gah, @Bill Sheboy you beat me again!

Great job asking if @Tyler Monroe might be on Data Center. If so, then he might have access to the ScriptRunner JQL Functions that I mentioned that could make this much easier.

But as I mentioned, you and John already solved this for Cloud w/o access to ScriptRunner functions.

Bill Sheboy

Yes, and...I neglected to add the dynamic JQL in that prior question's response, so I added it this time :^)

Darryl Lee

BTW, I cribbed that JQL from this article:

How can I search for all tickets that have issue links to another project?

Which links to this great thread about using the ScriptRunner functions to search for specific linked issues:

Filter to find issues with links to other issues which are unresolved

But again, the huge caveat is that you would only be able to do this if you are on Data Center and have ScriptRunner, because Adaptavist (ScriptRunner's vendor) is not able to make those functions available in "regular" JQL queries, such as the ones that Automation uses.

Darryl Lee

OH man, dynamically generated JQL. I didn't think about that.

I thought you could just iterate through each issue from the original lookup, but augh, yeah, I guess that'd require another branch, which is a no-go.