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
Next: Root
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
We have a complex structure in Plans, I have a rule to copy certain field values in "Child" issues when I link an Epic to an Initiative.
When I link in Plans, the Epic is updated with new "Parent Link" value, but the Initiative (in this case the Parent) has no update (even issue history does not show this change) and therefore does not trigger the rule with "Issue Updated" trigger. I need the Initiative (parent) to be the trigger issue since I am using "Copy field value from trigger issue" to edit the Epic (child). I need this to be the case because if I use the Epic as a trigger then copying values using {{issue.parent.customfield_xxxxx.value}} and {{issue.Parent Link.customfield_xxxxx.value}} does not work.
I have a workaround already which involves two rules and works as follows:
Rule 1: Issue updated > IF "Parent Link" is not EMPTY > Branch Rule JQL: issuekey = {{issue.Parent Link}} > Add comment
Rule 2 (Allowed trigger from other rules): Issue commented > Branch Rule JQL: "Parent Link" = {{issue.key}} > Edit Issue: copy fields.
BUT these don't cover cases where links exist and the field values are changed, I will probably need another rule for it.
All of this could be avoided if the parent was updated when linked through Plans, does anyone know why linking through plans does not update the parent? or a way to trigger the update event?
Hi @Michael Wu -- Welcome to the Atlassian Community!
That seems to be a known issue for the Cloud and Server versions of automation. You may vote for / watch this item (and the linked ones) here: https://jira.atlassian.com/browse/AUTO-377
For now I believe your work-around is a good approach...as long as the comment is specific enough and there is no human "tampering" with the comment.
Kind regards,
Bill
Hello @Bill Sheboy thank you! voted and watched!!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.