Automation HELP! Custom Fields editing Parent

[Casey_Jones]

Heres the gist. We have a custom field for stories/sub-tasks called "migration blocker" (yes, no). We also have a dashboard showing all Stories, required for migration by sprint.

We're running into issues where a story will have 5 subtasks on it. 4 of which are required for migration, one is not. So I'd like to automate that when the 4 marked ("required for Migration" = yes) are done, the custom field on the Parent story changes "required for migration" to no, thus taking it off my dashboard.

From the start the story needs to show it's required for migration, as 4 of the 5 subtasks are, but once that's completed we no longer need to track it towards this specific deadline.

I made this automation, but I don't think it will work after looking at it because I need ALL subtasks marked 'Yes' to be done as well as if there are say, only 2 subtasks but neither are required for migration to automatically changes the story's custom field to "no".

[Stephen Wright _Elabor8_ · Accepted solution]

Hi @Casey_Jones 

If I've understood your need correctly:

• Five Sub-tasks are created - 4 Yes, 1 No
• When the 4 Yes Sub-tasks move to "Done"...
• Change the field value on the parent from Yes > No

If so, this is how I did it:

1. Trigger: Issue Transitioned = Done
2. Add a Branch: Set "Type of related issues" to Parent
3. Add a Condition: Related Issues Condition - set "Related issues" to sub-tasks, Condition "None match specified JQL", and JQL to status != Done and "Required for Migration" = Yes
4. Add an Action: Edit Issue - Choose to set the "Required for Migration" field to "No"
5. Give it a name and publish it

^ The Condition checks each time a sub-task is moved to Done to see if there are any other issues which aren't in Done which still require migration. Using "None match" ensures absolutes against the 4/5 - as opposed to "some" or "all".

Let us know if this works for you!

Ste

[Casey_Jones]

Would this work if the 5th subtask (the one not required for migration) is not done?

Shouldn't I add after the trigger, If issue type equals sub-task?

otherwise wouldn't it run if the story is done? 

My dashboard is set up for all stories != done as at a higher level we're only tracking current WIP.

[Stephen Wright _Elabor8_]

Hi @Casey_Jones 

Yes it would still work regardless if the other sub-task is open or closed.

The branch "Parent" is based on sub-tasks - so it assumes the trigger issue was one. There is a separate branch option for Epic - "Epic (Parent)"

This means closing the story would not trigger an action, even though the trigger requirement is met and it might show up in the audit.

To make it a little cleaner, you could add in the additional condition - so the rule would be:

1. Trigger: Issue Transitioned = Done
2. Condition: Issue Fields Condition - set "Field" to Issue Type, "Condition" to equals and "Value" to Sub-task
3. Add a Branch: Set "Type of related issues" to Parent
4. Add a Condition: Related Issues Condition - set "Related issues" to sub-tasks, Condition "None match specified JQL", and JQL to status != Done and "Required for Migration" = Yes
5. Add an Action: Edit Issue - Choose to set the "Required for Migration" field to "No"
6. Give it a name and publish it

Ste

[John Funk · Accepted solution]

Hi Casey - Welcome to the Atlassian Community!

I think I would probably trigger it off of any sub-task that moves to Done that has a value of Yes for the Migration Blocker. 

Then take a look at the first use case in this article to see how to check on the parent and update it:

https://www.atlassian.com/software/jira/guides/expand-jira/automation-use-cases

Take a swing and that and post back what you come up with.  :-)

[Bill Sheboy · Accepted solution]

Hi @Casey_Jones  -- Welcome to the Atlassian Community!

If I understand you correctly, the workflow of your use case is:

• When an issue moves to Done
• And the issue is a sub-task
• Get the parent info (maybe with the temp variable feature)
• For the sibling sub-tasks
  • Are they all done?
    • If so, make the parent's migration "no"

Is this what you are describing?  

I wonder about your edge case of 2 sub-tasks that were never set to migration "yes".  Why would the parent's migration be "yes" for those?

Best regards,

Bill

[Casey_Jones]

There is no default setting, so the story wouldn't be set to 'yes' or 'no'. But if all subtasks are not required, ' I would like the story to be set to 'No' so it get's pulled out of the dashboard.

Unfortunately I'm not allowed to make it a required field.