Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Celebration

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root

Avatar

1 badge earned

Collect

Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!

Challenges
Coins

Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.

Recognition
Ribbon

Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!

Leaderboard

Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,457,584
Community Members
 
Community Events
176
Community Groups

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

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.

automation.PNG

2 answers

1 accepted

2 votes
Answer accepted
Daniel Ebers Community Leader Jul 04, 2021

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.

grafik.png

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

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? :)

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.

diffappr.PNG

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:

grafik.png

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

Like Bill Sheboy likes this

@Daniel Ebers It worked! :) Thanks a lot! :)

Daniel Ebers Community Leader Jul 11, 2021

@Wojciech Klupś I am so happy to hear, have a nice week!

0 votes

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

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.

Suggest an answer

Log in or Sign up to answer
TAGS

Atlassian Community Events