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; } } }

Update Issues in branching based on a lookup

Jan-Hendrik Wolf

Hi,

I have following use case, which already works

When a new issue is created (Trigger)

look, if there are already existing issues with similar information based on JQL (Lookup)

Create a new ticket with some information of all found issues (Create new issue)

for every found ticket (JQL-Branch)

- create a comment (Create a comment)

- link it to new created ticket (Link issues)

Now my question:

Is it possible to use an advanced Branching instead of JQL-Branching to achieve the same outcome?

It is highly dissatisfying to use the same JQL two times instead of reusing the "code".

When I switch the branching type, the comments and links were added to the triggerissue, instead of the issues of the lookup result.

Do I have to access the lookup result in a special way other than "{{lookupIssues}}"?

just for info: I simplified my usecase. The JQL is more complex in reality and I need the lookup result also in some if conditions.

Accepted answers

Mark Segall

Hi @Jan-Hendrik Wolf and welcome to the community!

Unfortunately, this is not possible. There's a request with only a few votes to allow branching against Lookup Issues results here:

https://jira.atlassian.com/browse/AUTO-461

So, you're doing things the right way given the constraints.

All comments

Bill Sheboy

Hi @Jan-Hendrik Wolf -- Welcome to the Atlassian Community!

First thing, what problem are you trying to solve by doing this (i.e., why do this)? I ask because what you describe, "if there are already existing issues with similar information", does not match the JQL used, as that only tests on status; there is nothing matching to the created issue.

For your other questions:

Is it possible to use an advanced Branching instead of JQL-Branching to achieve the same outcome?

Yes, and no. There doesn't seem to be a purpose shown for your lookup issues action. I suppose you could be using that in the issue create, although that is not visible. Thus your JQL branch could be changed to iterate over the keys found from the lookup, reducing the use of the original JQL. Or you could just remove the lookup.

It is highly dissatisfying to use the same JQL two times instead of reusing the "code".

Please see above. And...are you commenting on the use of the JQL or the definition of the JQL expression? If it is the latter, you could define the JQL in a created variable and then use that in both places.

When I switch the branching type, the comments and links were added to the triggerissue, instead of the issues of the lookup result.

Without seeing that rule structure it is unknown why that symptom happened. My hypothesis is you tried to branch on current issue. Please post that rule image if you need more help with this one.

Do I have to access the lookup result in a special way other than "{{lookupIssues}}"?

The only way to access the results of Lookup Issues is with the {{lookupIssues}} smart value. The general purpose of Lookup Issues is to gather from 0 to 100 issues meeting some criteria so that can be used as a set, such as for summing values, reporting the set, etc. What else are you trying to do which requires some alternative access method?

Kind regards,
Bill

Mark Segall

Hi @Jan-Hendrik Wolf and welcome to the community!

Unfortunately, this is not possible. There's a request with only a few votes to allow branching against Lookup Issues results here:

https://jira.atlassian.com/browse/AUTO-461

So, you're doing things the right way given the constraints.

Jan-Hendrik Wolf

Hi @Mark Segall

thank you for your answer. Good to know, that I don't have to look further in it. :-/

Regarding the votes, this problem is a personal one

Jan-Hendrik Wolf

Hi Bill,

first of all. Thank you for you fast response

Let's get on your questions:

First thing, what problem are you trying to solve by doing this (i.e., why do this)? I ask because what you describe, "if there are already existing issues with similar information", does not match the JQL used, as that only tests on status; there is nothing matching to the created issue.

As mentioned, I simplified the automation in my comment. The real query in the lookup is:

"System (Assets)" = {{issue.System (Assets).Name}} AND assignee = {{issue.assignee}} AND Status not in (Done, Geschlossen, Erledigt) AND reporter = {{issue.reporter}} AND issuetype != Massenänderung

Now I am accessing the field "Rollenname" in every found issue to populate a multivalue asset field while creating a new ticket.

Key in ({{#lookupIssues}}{{Rollenname}}{{^last}},{{/}}{{/}})

lookup and create ticket.PNG

After creating this new issue, I want to update the found issues in the lookup. To iterate over them, I am using the same query.

While I was writing this, Mark already crushed my dreams for a perfect solution as https://jira.atlassian.com/browse/AUTO-461 describes my problem perfectly.

But can you explain, how you meant this

And...are you commenting on the use of the JQL or the definition of the JQL expression? If it is the latter, you could define the JQL in a created variable and then use that in both places.

Is it really possible to define a JQL in a created variable and use it afterwards in Lookup and Branching?

Bill Sheboy

Yes, that is possible, and it is necessary in some cases.

For example, there are smart values / fields provided by marketplace addons that are dynamically populated. Those can only be in simple reads, and not in more complicated smart value expressions. So the work-around is to first store them in a variable, and then concatenate together the values for a JQL expression...then use that where needed. This is very helpful when calling issue lookups with the REST API.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-service-management-cloud

jira-service-management