Jira automation question

[Julia]

My Kanban board is set up so that Epics belong to the Product Managers who then create tasks from the Epic for other team members. I have the statuses To Do, In Progress, Test, Blocked and Done. I am trying to automate the behavior of the Epics so they move between statuses based on when people are moving the tasks between statuses and I've cracked it apart from one scenario :-

When the children of an Epic are in more than one different status, move the Epic to In Progress.

This is to perform as a "In Progress is the default" as I have other rules which are such as "When all children are in Test then move Epic to test". I have been trying with the different options in the Rule builder but getting nowhere near a solution.

Note : Installing a plug in for more functionality is not an option for me

[Bill Sheboy]

Hi @Julia -- Welcome to the Atlassian Community!

From what you describe, it is possible your different rules are colliding and updating the Epic repeatedly.

For a scenario such as this, I recommend using one rule to update the Epic for the basic case.  To do so, please try:

• Define the behavior you want for the different conditions of the child issues and pause to write it down fully.  (This will help with later testing.)  Remember to include any edge cases and decide if you want to handle them with additional rules.  (e.g., adding an already in-progress child to the epic)
• Create a rule triggered on any transition to handle the basic case...
  • trigger: issue transition
  • condition: check the issue type is a Story, Task, or Bug (or your other child of Epic types)
  • condition: check if the issue has a parent
  • action: lookup issues with JQL to gather the sibling child issues of the Epic
  • action(s): using create variable or create lookup table, gather the counts of the issues in each possible status which is relevant
  • if / else conditions... using the behavior you defined, use conditions in the correct order to decide if the parent should transition
    • when needed, branch to the parent Epic inside the condition to transition it
• When handling the edge cases are needed, add additional rules which clone the above logic.  These edge cases may include at least:
  • Issue created and assigned to the parent Epic
  • Issue deleted and removed from the parent Epic
  • Parent Epic changed for an issue
  • Parent Epic is transitioned manually, and so overrides the automatically determined status

Kind regards,
Bill

[Julia]

Thanks, I've picked up a a lot of pointers from what you have said and decided to concentrate on putting the existing rules into one as the first phase:-

All in To Do = Move Epic to To Do

All in Test = Move Epic to To Test

All in Blocked = Move Epic to To Blocked

At least one In Progress = Move Epic to In Progress

I'll look at the other Epic scenarios and other actions performed on the tasks apart from transitioning statuses at later date.  Also worth noting we don't use Stories and only the statuses of Tasks need to effect the Epic. I have had an attempt at a new rule, but its very messy, especially as I cannot find a "If/then/Else" component to use, only IF. Can the below be done better ?

[Julia]

The picture has been truncated on posting, here is the final piece

[Bill Sheboy]

The if / else condition cannot be used inside of a branch on Parent.  And so the way you wrote your rule will stop as soon as it fails a condition.  That can be inverted, with the branch inside of the conditions...

The rule structure I was suggesting is more like this, using create variable, math expressions, and list iteration:

• trigger: issue transitioned
• condition: issue type equals Task
• condition: issue Parent exists
• action: use lookup issues to gather the issues in the same parent as the trigger issue with
  • parent={{triggerIssue.parent.key}} AND issueType = Task
• action: create a variable to count the issues found
  • name: varTotalCount
  • smart value:
    • {{lookupIssues.size|0}}
• action: create a variable to count the issues in "To Do"
  • name: varTodoCount
  • smart value:
    • {{#=}}0{{#lookupIssues}}{{#if(equals(status.name,"To Do"))}}+1{{/}}{{/}}{{/}}
• ...repeat for the other counts needed
• if / else condition
  • smart value condition:
    • first value: {{varTodoCount}}
    • condition: equals
    • second value: {{varTotalCount}}
  • branch: to parent
    • action: transition to To Do
• else / if condition
  • repeat for the other needed checks

If you want to shorten the rule a bit, you could use a single Create Lookup Table action in place of the create variable actions:

• action: create lookup table
  • name: tblCounts 
  • row
    • key: Total
    • value: {{lookupIssues.size|0}}
  • row
    • key: ToDo
    • value: {{#=}}0{{#lookupIssues}}{{#if(equals(status.name,"To Do"))}}+1{{/}}{{/}}{{/}}
  • ...add a row for each count
• ...
• to perform the comparisons, lookup the values from the table
  • smart value condition:
    
    • first value: {{tblCounts.get("ToDo")}}
    • condition: equals
    • second value: {{tblCounts.get("Total")}}

[Trudy Claspill]

Hello @Julia 

Welcome to the Atlassian community.

When asking for help with an Automation rule, it will help us help you if you provide screen images showing your entire Automation rule and the details of each step. It is also helpful if you explain what is not work or the part with which you need help. If the rule is running and not producing the expected results, include the output from the rule execution log, and tell us what results you expect vs. what you actually get.

In this scenario it sounds like you may also have multiple rules running to change the Epic status, so please provide screen images for all the rules that you are using to change the Epic status.

[Julia]

I have one of these each for To Do, Blocked & Test, but they move the Epic if ALL the children are the matching status (and they work fine). The one I am after is to move the Epic to In Progress if the children are multiple different statuses so it shouldn't clash with these three rules. (Moving to Done is required to be done manually as it is linked to another process)