What trigger to use in automation to detect a sub-task got moved from one issue to another?

[Parcandi Administrator]

Hi everyone,

this question is NOT about transitioning through workflow (sometimes also called "move"). This question is about moving sub-tasks between issues.

Background:

• Sometimes during sprint planning we split stories up into multiple stories. Then we want to move already estimated sub-tasks to other stories.
• We estimate story points on sub-tasks and through automation sum the story points up to the parent. The automation triggers when the sub-task story point estimate changes
• If we now move already estimated sub-tasks between issues, the sub-task estimate doesn't change and the automation doesn't trigger. Consequently, the moved estimate doesn't reflect on neither the previous nor the new parent 

First question: What trigger shall I use in automation to detect a sub-task got moved between issues?

I would then wish to re-calculate the parent story points from the sub-tasks on both the previous and the new parent of the moved sub-task 

Second quesion: How could I address re-calculation on both affected parents by one rule?

Thanks in advance & Cheers

Ralf

[Alex Koxaras -Relational-]

Hi @Parcandi Administrator 

For your first question, my bet would be to monitor the Parent Link field for any changes and compare the previous with the new value.

For your second question I would begin by following this automation template and make any necessary modifications. 

[Bill Sheboy]

Hi @Parcandi Administrator 

Yes, and...to Alex's suggestion:

You do not show an image of your current rule, so it is difficult for the community to give you focused guidance.  Please consider posting your rule to help provide that context.  Thanks!

Regarding your second question: depending upon your current rule, you may not be able to do this in one rule.  Instead, you could have a second rule triggered on some field value change (e.g. commented added noting "Recalculate the story point total") to sum the points for the story from which the subtask was removed.  This could become your primary rule for recalculation (i.e. move the sum logic to the new rule, and change your current rule to just add the triggering comments).

Kind regards,
Bill

[Parcandi Administrator]

Hi @Alex Koxaras -Relational-

thanks for your reply.

Regarding question one

• I tried the "parent link" as well as the "subtask count" field. Both didn't work as triggers
• I wasn't able to select the "Sub-tasks" field to trigger the automation even though I can select the field for display in filter queries

Regarding question two, I know about that template and used it already for summing up story points upon the change of story points in sub tasks. My question relates more to whether

• there is a field on the two parent issues I could use as the trigger. Then probably I would need only one rule only because that rule would apply to both parents

or whether

• I would need a field on the subtask as the trigger. Then, after the move, the previous parent is no longer accessible and I need to recognize that previous parent anyway by another trigger. Which would need two rules instead of one

But I think question two gets answered instantly once it is clear what field to query to get the automation activated

Kind regards

Ralf

[Parcandi Administrator]

Hi @Bill Sheboy cc: @Alex Koxaras -Relational- 

the rule based upon "Subtask count" is the following: According to my understanding, this should work for both parents

The rule base upon "Parent link" however I deleted already for it didn't work and I needed another rule for the old parent anyway. It was similar to the follwing rule but just using the "Parent link" field as its trigger:

Kind regards

Ralf

[Bill Sheboy]

Hi!

I tested this a while ago, and can confirm that you cannot yet detect in a rule when the parent changes as it is not supported in the changelog.  To be clear, the "issue updated" trigger can fire, but the changelog does not record the parent change.

@Parcandi Administrator   Is subtask count a custom field you are manually setting, or perhaps based upon a schedule or issue created trigger?

[Alex Koxaras -Relational-]

Wait up!!! I've done it! I just have to tuck my daughter to bed and I'll post the rule

[Alex Koxaras -Relational-]

@Bill Sheboy as always you were on the right track, with the exception that changelog works like a charm:

• Issue updated is the trigger to go
• Add an if statement to check is the old parent is equal to new parent
  • Brach rule for the current parent
    • Edit issue by calculating story points like in the library
  • Branch issue for JQL that key is equal to the old parent
    • Edit issue by calculating story points like in the library

I wasn't able to post it earlier, since I had personal things to attend to :)

[Bill Sheboy]

Thanks, Alex!  I last tried that with changelog about a year ago...I think.

Did you test that rule with a move operation?  How about with company-managed versus team-managed as they have different parent handling?

[Alex Koxaras -Relational-]

Yes I did move three times subtasks from one parent to another and works as it should be! I didn't try on TMP, since I find myself always playing in CMP. Perhaps I'll give it a go and see if I can come up with anything!

[Bill Sheboy]

Awesome!  And I believe that as you have implemented the rule with branches, it may also handle the case of issue type conversion/move: sub-task to story, or the other way around.

[Alex Koxaras -Relational-]

So far what I've implemented works only for when subtasks are moved to a standard issue type (only child-parent relationshp)

And in TMP there are a few differences:

1. The changelog of the parent does not yield any results. No matter how I tried, I couldn't get the previous value.
2. You have to calculate the story point estimate sum
3. Changing parent is a different action that MOVE (didn't know that to be honest)

So in TMP I couldn't manage to make it work. I'll try a bit more, I don't have high hopes.

[Bill Sheboy]

"Move Issue" trigger doesn't execute when moving issues to same project

https://codebarrel.atlassian.net/browse/AUT-1526

[Alex Koxaras -Relational-]

So it's a bug! :)

Still have to find a solution about the parent change log. Maybe this is a bug as well and not recorded on history? I mean {{issue.fields.parent}} gives you the current key. {{changelog.parent}} ought to work.