Update fixVersion on sub-task with value from parent on change of parent

[Stephan Grubbe Sølby]

We have a regular 3-tier hierarchy Epic,->story->sub-tasks.

The use-case is that occasionally, the parent of sub-tasks changes (move sub-task to different parent) and in this case, we would like to update the fixVersion value of the sub-task with the value of fixVersion of the new/updated parent.

We are trying to use a rather simple automation for this:

However, the result is that it copies the fixVersion from the original parent and not the new parent.

So, if original parent TEST-1 has fixVersion Release 1 and TEST-2 has fixVersion Release 2, moving a sub-task from TEST-1 to TEST-2 copies the Release 1 (which in fact is the version the sub-task already has), moving it back from TEST-2 to TEST-1, the sub-task gets Release 2 (not a likely use-case at all, but included to demonstrate the point).

I realize, it might not be correct usage of the hierarchy, but the team requires fixVersion on sub-tasks for other statistical reasons.

I tend to think this is a bug, since the trigger is the change itself (i.e. it has happened), but obviously it does not work as anticipated by me.

Does anyone have a solution for this?

[Trudy Claspill · Accepted solution]

Hello @Stephan Grubbe Sølby 

I had the same experience as you.

I solved it by adding a Re-Fetch Issue action immediately after the trigger.

[Bill Sheboy]

Hi @Stephan Grubbe Sølby 

Adding to Trudy's answer...

I saw this symptom earlier this week helping with a related question.  There are definitely problems with the changelog in automation rules when changing a sub-task's parent.  And apparently the triggers do not consistently fire for changing the parent.  (For example, "convert to subtask" and "convert to issue" versus the full version of "move" from the UI.)

Perhaps consider submitting a support ticket for this so the Atlassian team is aware of it: https://support.atlassian.com/contact/#/  (I am unable to do so as I'm on a free license :^)

Kind regards,
Bill

[Stephan Grubbe Sølby]

@Trudy Claspill I didn't know about the re-fetch action. I've now implemented this and it works. Thank you.

[Stephan Grubbe Sølby]

@Bill Sheboy Thanks for providing context. My use-case was move from the UI. I did open a support request. They also came back with the re-fetch, so it's closed again. I can imagine use-cases where data from the original parent would be useful, so I'm reluctant to calling this a bug.

[Bill Sheboy]

I am glad to learn you have something that is working!

(And yet Bill continues...  :^)

To me this symptom is a defect...changelogs have lots of problems in automation rules, often due to timing.  However I have a couple of other hypotheses, based on no actual knowledge of the Jira automation engine implementation:

• Unlikely one: the automation engine is subscribing to the wrong events for a trigger when a rule is enabled, and so the callback does not happen when expected
• More likely one: there are lots of paths through Jira for things to happen (e.g., change of parent), and either events are not raised for all possible paths or there are different events for those edge cases; as a result, the automation team never knew to look for them to subscribe