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
I am quite certain this won't work but I want to find a solution.
I have an automation which triggers on create issue and then looks if an issue is a subtask. The actions only work on subtasks created.
I have noticed a scenario where an existing issue (not subtask), is assigned a parent, making it a subtask now. i also want my automation to run on this subtask but since it was not a new issue created, I don't think the create issue trigger will work.
What trigger can I use that covers both the cases. New subtask created or existing issue changed to a subtask.
Thanks.
Hi Bill,
I was hoping to find a trigger which works on create or update. But looks like conversion to subtask doesn't have any trigger. https://jira.atlassian.com/browse/JSWCLOUD-22432.
Due to this known bug, I can't use the update trigger.
The scenario is that I want certain values to be copied over from parent to subtask. I did it with an automation that is working fine, but if an existing issue (non-subtask) is converted to a subtask, this automation won't trigger.
FYI to please try to keep to one thread when responding. That will help others looking at this question in the future know if there are multiple solution approaches. Thanks!
Yes, I knew about that defect. And, I just tried converting a story to a sub-task (with a move operation) and it did trigger the issue updated event to start a rule.
How is your team editing the parent field directly to cause this condition? Would you please show screen images of those steps?
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.
After a I bit more testing I confirmed that with that button / action, it must take a different path through the move logic: only the "to" in the change log is set and not the "from".
And so the remaining work-around would be to still use 2 rules:
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.
For the scenario you describe, I believe you may want two rules until you work out the details, and then you can experiment with one rule, using the Multiple Issue Events trigger.
The challenge is your rule will need several conditions to handle the change of the issue type (or parent).
What does your rule do and how often do the two scenarios occur (create versus change of parent)? If the second one is infrequent, using separate rules may be better to manage the complexity of the rule.
Kind regards,
Bill
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.