You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
I want to have an automation rule in Jira Software Cloud that when a linked issue of "Caused By" Issue Link Type is transitioned to "Done" status, If that is the only remaining open ticket linked to this parent ticket of that issue link type, Then this parent ticket will update field X with resolution value from that linked issue and transition to status "Ready for Acceptance".
Can do it very clearly in JSD (https://support.atlassian.com/jira-service-desk-cloud/docs/when-if-and-then-statements/), but I have been having a difficult time finding that in Jira Software Cloud
Not sure I understand how or where the "Parenting" is in your scenario. Reads like you have a one to many linked issues setup, where the one "master" issue is not a parent, but simply has a number of linked issues...do I have that right?
My hunch is, this would be a lot easier if instead of just a series of linked issues, there was a hierarchy in play. Epic to stories or Story to Sub-tasks.
Gah... don't even know how I switched to use "Parent"... lol... good catch/call-out... Yes... Here's the vision of what I'm grabbing for...
1) A Story (I'll call this issue "Build this Widget") has issue-link-type of "Caused By" (for example) to another issue (not in the same hierarchy (I'll call this issue "Service-Update" for reference), could even be in another project entirely.
2) "Service-Update" moves to "Done" status with a resolution of "Deployed".
3) "Build this Widget" sees this happen, and seeing that there are no other open issues of that issue-link-type of "Caused By", it transitions to "Ready for Acceptance" and copies the "Deployed" resolution from "Service-Update" to a custom field in the "Build this Widget" screen.
Clarification: I want this to be defined inside the project for "Build this Widget" (so a "Pull" automation) NOT something that the project that "Service-Update" is in, requiring it to send an automation call (a "Push" automation).
Hope this clears it up :-)
Best I can think of is run a scheduled job with JQL of:
issueLinkType in ("Caused By") AND status = Done and resolution = Deployed
Then use an "if else" along the lines of:
Note: I used "is tested by" as the link type, but you would use your "Caused by" one.
Then use the "edit Issue" action to configure your step 3.
Worth a try???
OOOO I like that! I wonder if there is a recommendation from Atlassian on "not to exceed" frequency on automation schedules? I think the main interest is in having this execution happen as near-real-time as possible, but I could potentially leverage an "Alert" query I have done in the past for alerting notifications where people can subscribe to entire sets of data under a saved filter like:
project = "Critical Project Z" AND issueType = "Customer Reported Issue" AND StatusCategory != Done and Status != "Ready for Release" and priority = Blocker and updated <= -15m and assignee is EMPTY
Then they subscribe to it with a recurrence of every 15 minutes, (without it sending an email if no results found). So this becomes a system that can alert people if there is a critical show-stopper customer reported issue raised that has not yet been grabbed by someone on the team to start reviewing...
SO that would translate to the query you shared modifying to this:
issueLinkType in ("Caused By") AND updated <= -15m
And then setting the scheduling recurrence to run every 15 minutes... Just concerned I'd bork the system performance lol. Think that might work?
@Russell Zera I think it could.
That was why I just opted for a schedule, as I couldn't think of another way to "trigger" the event.
I don't think it matters how often you run the schedule. What matters is how many updates it is likely to do per "schedule", as that is where the grunt is.
Plus, whether you intend it to be a single project, Multi project or Global automation. Particularly f you are not a premium customer and have to watch your Multi project/global executions.