change parent if all subtasks (with separate issue type) are done

[Jan de Beijer]

I want to change the status of a parrent when all subtasks with a separate issue type are done.

for example:

I have a story with 8 subtasks,

3 subtasks have issue type "subtask

5 subtasks have"custom issue type "dev subtask".

if all the subtasks with issue type "dev subtask have status "done" than change the status of the parent.

(the other 5 subtasks can have different statusses).

[Taranjeet Singh]

@Darryl Lee I just stumbled upon this post. That's a great help from you on this automation rule!

Great to see that it is now working for a newbie automation user like @Jan de Beijer !

Keep up the great work!

[Darryl Lee]

So glad you got it working!

To understand a little more about Smart Values, specifically the one in question, {{lookupissues.size}}.

When you use a Lookup issues action, it returns a list of issues. So you can then use list functions to get things like the number of issues it finds. That's what the .size part is about.

[Jan de Beijer]

Thanks Darryl for your patients with me. as i told you i'm a newbe. and the {{lookupissues.size}} was the solution. thank you very for your help. I think there will be one day that also i will understand the smart values.

kind regards Jan.

[Darryl Lee]

Hey @Jan de Beijer OK, thanks for sharing more of your rule. I see the problem!

The variables {{totalDevsubtasks}} and {{totalDevsubtasksDone}} must have the value of:

{{lookupIssues.size}}

This is the key. That is a Smart Value returned by the Lookup Issues component.

They should look like this:

[Jan de Beijer]

Hello and sorry Darryl to bother you again with my issue (thanks again for your repley).

I think i do something wrong with my counts, because i did the following in the log.

and in the log audit it say's (no counts)

so the log don't tell me a count.

In the "lookup issues i have

and in the "create variable"

my compleet rule looks now like this: 

[Darryl Lee]

Hey yeah, hopefully we are getting closer! So the Log action doesn't actually do JQL queries or anything. It can basically only "print" stuff, like whatever variables you already have.

SO to get the counts, you could just insert Log action after each Create variable component like this:

 

[Jan de Beijer]

Hellow Darryl,

i googled a lot about the log output into the automation rule, but as i told you i'm a newbe (sorry for that).

Now i think i understand how to use the "log action" into the rule.

so first i put the "log action" into the rule with "Issuetype = {{issue.issuetype}} the respons was a issue type number, so now i think i understand the meaning of "log action" but i realy don't now what i have to put into the "log action" so that he will give me back the counts he did.

i just put in the rule, but that is not working, can you give me 1 example of my rule.

for example what should i put in the action log, so the result is the counts of the number of issue types (development subtask) with status "done" so i have something to play with.

thanks

[Jan de Beijer]

hello Darryl, i'm just a newbe in Jira,

Sorry, but i don't understand your comment:

I would start inserting this maybe at the beginning of the rule, and just have it output:

Issuetype = {{issue.issuetype}}

I also used this to get the values of the variables I set, just to make sure everything was working as expected, and for instance to see the # of Done vs Not Done sub-tasks.

where and how should i put that in my rule??

i didn't change anything and start the rule again, so now i have only 1 rule loged instead of the log for all subtasks. 

where is CN-98 is my parent

and CN-118 and CN-120 are my development subtasks.

so i wil put the suggestion of you as mentioned 

Issuetype = {{issue.issuetype}}

into my rule, but i don't now what you mean and where is  should put in in which way. 

[Darryl Lee]

Hrm, I just tested again and it doesn't matter if the trigger specifies transition to Done or not (although you should probably do this to reduce the # of times the rule runs, as that can be limited, depending on your tier).

I can see my issuetypes are different depending on which sub-tasks I transition. The question is whether your tests show the same thing.

[Darryl Lee]

Hi - I got this to work for me with issuetype. I made my rule look just like yours.

So are you saying that CN-118 is NOT a Development sub-task? That's odd. The first IF statement should have not matched and you should be seeing "No actions performed", not "Success".

OH! One difference I noticed is that your trigger is not specifying Transitioned to Done! Maybe that is the problem!

One very useful thing for debugging rules is to use Log action.

• Debug an automation rule 

I would start inserting this maybe at the beginning of the rule, and just have it output:

Issuetype = {{issue.issuetype}}

I also used this to get the values of the variables I set, just to make sure everything was working as expected, and for instance to see the # of Done vs Not Done sub-tasks.

Good luck - let us know how it goes.

[Jan de Beijer]

Hello Darryl, i think i'm very close now.

Thank you very much for your quick and clear answer. I'm sorry, but a already created a new issue type (sub) named "Development sub-task" and i tried to change your field flow to the issuetype flow like this:

on number 3 i have the following JQL:

parent={{issue.key}} AND "issuetype" = "Development sub-task"

and on number 5 i have:

parent={{issue.key}} AND "issuetype" = "Development sub-task" AND STATUS="Done"

I published the rule, and tested it. in the "audit log" he executes the rule for every subtask thas is related to the story (for the regular "subtask" and for the "Development sub-task" and on every execution the log says:

I hope you can help me again. if the issuetype is the problem than i go back to the custom field.

[Darryl Lee]

AH, ok, thanks for the clarification.

So the key is that ALL of the subtasks of a certain type (let's stick with a Custom Field I've named "Subtask Type") have to be done. Got it.

I think this should work:

The trick is that I'm doing two Lookups:

parent={{issue.key}} AND "Subtask Type" = "Development"

That's all of Development subtasks that need to be done. I then store the # of issues that matched, {{lookupIssues.size}}, to a variable: totalDevSubtasks 

And then I check for how many Development subtasks are actually done:

parent={{issue.key}} AND "Subtask Type" = "Development" AND STATUS="Done"

And that # gets stored in totalDevSubtasksDone.

Then I do two checks:

1. Is totalDevSubtasks not equal to 0?

AND

2. Is totalDevSubtasksDone equal to totalDevSubtasks

If so, then move the Parent to Done!

Please let me know if this is closer to what you needed.

[Jan de Beijer]

Hello Darryl, thank you for your reply, but maybe my example was not written clearly.

the number of subtask can be any numbers so in my example it was 5 and 3, but it can also be 2 and 3. It is just about the difference in the subtasks.

i  also tried to make another subtaske issue type and do it that way. but i also have no solution for that methode.

this last mentioned situation i would like to do the following:

example:

story has 6 subtasks

2 with issue type "subtask"

4 with issue type "subtask-development"

(numbers of subtasks can be random).

if all subtasks with issue type "subtask-development" are done, than change the story to another transition.

the status of the issue type "subtask" are inrelevant, so can have alle statussen.

maybe that is an easier way?

[Darryl Lee]

Hi @Jan de Beijer -

So I'm going to go forward with your example assuming they are not optional, but requirements.

Note that this does not check to see if you have exactly 8 subtasks. It does check if you have exactly 3 subtasks with custom field X filled and exactly 5 subtasks where custom field is empty.

You'll probably want to do more testing than I did, but it tried my first time, so I'm calling it a night. :-}