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

Break from automation rule when one of subjects did not match the condition

Wojciech Klupś

I have an issue and I want to check if assignee of that issue is an assignee in subtasks and if not, do something. Problem is, that when I branch rule to subtasks and check assignees, rule passes even if one of subtasks did not match the condition. I need opposite, even if one subtasks did not match the condition, do not go further. How I can achieve that? In example screen 1005 and 1004 are subtasks of 1003.

Accepted answers

Daniel Ebers

Hi @Wojciech Klupś

"Lookup issues" some kind of accepts also JQL in its query.
I tried to reconstruct your requirement and from the looks it was successful to some extent.

Not sure if the whole requirement is achieved by this - you would need to test and maybe adapt it.

The lookup is cut a bit in the screenshot and reads:
project = DEMO AND key = "{{issue.key}}" AND issuetype=Sub-task AND assignee != "{{issue.parent.assignee.accountId}}"

The rule checks when logging work into an issue if there are Sub-tasks which assignee are not the same like in the main issue.
If so, a log entry is made (this is where you probably have your external call via Webhook in via "Send web request").

@Bill Sheboy
despite it is working I hope there is no "no-go" in it - without the branch the "Lookup issue" function somehow referred always to the specific triggering issue for "issue." - and I was not able to introduce "issue.parent.key" either.
So the current configuration works but I feel there is something cumbersome with it, isn't it?

Happy to hear some feedback!

Regards,
Daniel

All comments

Bill Sheboy

Hi @Wojciech Klupś

Rather than using the condition and branch, you could use JQL to get the sub-tasks which have the assignee value(s) you care about, and if there aren't any then proceed.

Here's some information about Lookup Issues:

https://support.atlassian.com/jira-software-cloud/docs/smart-values-general/#Smartvaluesgeneral---lookupIssues--

Best regards
Bill

Wojciech Klupś

Hi, @Bill Sheboy ! Thanks for your reply.

That's good, but how in my example point parent issue in JQL? JQL is not accepting smart values and I can't pass exact issue key (like XC-1003) because it has to be global rule.

Daniel Ebers

Hi @Wojciech Klupś

"Lookup issues" some kind of accepts also JQL in its query.
I tried to reconstruct your requirement and from the looks it was successful to some extent.

Not sure if the whole requirement is achieved by this - you would need to test and maybe adapt it.

The lookup is cut a bit in the screenshot and reads:
project = DEMO AND key = "{{issue.key}}" AND issuetype=Sub-task AND assignee != "{{issue.parent.assignee.accountId}}"

Happy to hear some feedback!

Regards,
Daniel

Wojciech Klupś

Hi @Daniel Ebers ! Thanks for extensive response
I'm not sure still if it could resolve my problem. With your scenario I'll get list of subtasks which assignees are not same like parent issue. Which is ok, but from my side it doesn't matter how many of them they are. Even if one would be same assignee like parent, I can't pass further. So something like 'If' statement would be handy, but there are no 'If' statements when I'm in branched rule

To clarify my problem, condition is that:
When user logs time in parent jira, check if any of subtasks have this user as an assignee. If yes (even one of x), do nothing, if no, send external webhook.

So first of all, I could change != to = to search if there are any with similar assignee. But then still I would need to check if lookupIssues is empty.
Any hints on that?

Wojciech Klupś

I've tried different approach. But it's not working as intended (passing through condtition even if one of subtasks have assignee similar to parent). I think that this JQL could be messed up.

Daniel Ebers

I think now I understand your description/use case. Sorry that you needed to explain it that often.

Your rule almost looks working to me - issue.parent.assignee won't work though as we are operating on the main issue, not the Sub-task.

Again no guarantee - but in a (new) test now this seems to work in my environment:

Assignees ... for:

Issue: Alana
Sub-Task 1: Bob
Sub-Task 2: Caesar
Sub-Task 3: Doro

--> Fires as Alana would have to be assignee in at least one sub-task. OR a different assignee (one of the current 3 Sub-Tasks) must become Assignee in Issue.

Assignees ... for:

Issue: Alana
Sub-Task 1: Bob
Sub-Task 2: Alana
Sub-Task 3: Doro

--> does not fire as Alana is now Assignee of Sub-Task 2 what satisfy the requirement already.

Please test it again - as always happy for feedback

Regards,
Daniel

Welcome!

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

Quick Links

Find more posts tagged with

jira-cloud

automation