Jira automation for creating tasks

[Stephen C Hauer]

Hey guys,

Im looking for a way to create X number of tasks based upon a custom field I created. Ideally the automation would look at a create task template I created and then create a duplicate of that task X number of times. 

For instance If I specified, created 10 tasks from this task. It would duplicate all relevant data from the parent task. Right now I have a manual solution working using manual triggers. However this is not a flexible solution. I would love to know the best way to handle this kind of process. 

For this example Im filtering by the +5 custom field I created. To make this work currently I have to manually create 5 create task components. All of them will have the same settings so it feels silly I have to set this up.

I would love to know the right way to handle this!

[Bill Sheboy]

Hi @Stephen C Hauer 

One way to do this in an automation rule, for up to 100 items, is to create a source for an advanced branch from your counter field.  Let's assume that is called {{issue.myCustomFieldCounter}}

• Create a variable with an initial dummy value of NULL
  • name: varNull
  • smart value: NULL
• Create another variable to use as a looping source, using rightPad() with a delimiter and up to your count in length
  • name: varLoopSource 
  • smart value: {{varNull.replace("NULL","").rightPad(issue.myCustomFieldCounter, "Z")
• Split the created variable on the delimiter, and use that as the source for an advanced branch: {{#varLoopSource.split("Z")}}{{index}}{{/}}
• Create the issues inside of the advanced branch

This will produce an advanced branch with the value equal to the list index counter as it proceeds. 

Please remember that branches with more than one item process asynchronously and in parallel, so there is no guarantee of the processing order or when the branch will complete.

Kind regards,
Bill

[Stephen C Hauer]

@Bill Sheboy 

I love the idea but Im failing with the execution. 


Any chance you can provide a bit more guidance?

Here is my Structure


Null Variable

[Stephen C Hauer]

I attempted to set this up again and it succeeds but only one task is created. The loop appears to fail.

Any, additional help on this would be greatly appricated.

[Bill Sheboy]

My apologies...it appears that in the year since I developed this approach (March 2021) that the rightPad() and leftPad() functions no longer accept a smart value as a parameter for the count.  I'll experiment with this a bit to see if I can find a work-around, or if I am just missing something.

[Stephen C Hauer]

Thanks for the help on this @Bill Sheboy I appreciate the support!

[Bill Sheboy]

Hi @Stephen C Hauer 

Following up this thread...

Short version: There is a bug/design issue here, and I recommend working with your site admin to submit a ticket to Atlassian Support to take a look.

Longer version:

I found my complicated example rule which uses smart values as a parameter to rightPad() and it still works.  It uses information based on an integer field (date/time) in a lookup issues result, parses it a few times, and then correctly provides the padding count.

Every other test I tried with Text fields converted to numeric, native Number fields, or Created Variables converted to numeric failed.  My hypothesis is there is some data type issue which is preventing the use of anything that does not start as an Integer when entering the function...regardless of parsing.

Sorry for the delay in responding and that I couldn't find a work-around.

Kind regards,
Bill

[Scott Lund]

Hi @Bill Sheboy 

I've been searching high and low for a solution to this, and just wondering with the time that has passed, if this has been resolved?

Essentially I want to do something very similar, except, mine is a dynamic number contained in a custom field on the epic. On transition, I would like to have child issues created based on that number. 

Example: Paths = 4, so it would create 4 issues.

Any guidance, or update would be amazing thanks

[Bill Sheboy]

Hi @Scott Lund -- Welcome to the Atlassian Community!

I re-tried my test rule for this and it appears to work.  Here are the basics if you want to try it...I used "Story Points" as my counter field, so substitute with your own custom field. 

Please note: advanced branches occur asynchronously and in parallel, so there is no guarantee of the order the items will be processed in the branch.

• trigger: manual (I used this to get the rule working, and you can adjust as needed.)
• action: create a variable
  • name: varLoopValues
  • value: NULL
• action: create a variable, again with the same name to replace the values
  • name: varLoopValues
  • value: 

{{#varLoopValues.rightPad(varLoopValues.length.plus(issue."Story points"), "X").remove("NULL").replaceAll("X","X,").substringBeforeLast(",").split(",")}}{{#=}}{{index}} + 1 {{/}}{{^last}},{{/}}{{/}}

• advanced branch
  • smart value: {{varLoopValues.split(",")}}
  • variable name: varLoopVariable
    • action: do what you need, and reference {{varLoopVariable}} if you need the index

Here's a picture for context, with some extra audit log writes for tracing:

Kind regards,
Bill

[Scott Lund]

Hi Bill, 

Thanks so much for the reply. I have managed to get it to work - sort of. I can't get it to detect the value correctly in my field. 

I am using a field called Fiber Paths and the value ranges from 1 to x. The test case I am testing with is 3, however, reviewing the log it only ever changes from 0 to 1. 

I've copied your settings exactly, so just wondering, if I am missing something easy.

Cheers

Scott

[Bill Sheboy]

Hi, Scott.  Please post images of your complete rule and the audit log details showing the execution.  Those may help uncover what is happening.  Thanks!

Until then...my rule was using Story Points, and if your custom field is not a Number type, you may need to convert it with asNumber to make this work.

[Mark Segall]

Hi @Stephen C Hauer 

I think the best way to handle this is instead of using a field to determine how many tasks, you just use some obscure label as the trigger.  Then at the end of each execution remove the label.  The user just keeps reapplying the label as often as needed to get the desired number of tasks.  It's a little more work than typing in a number, but your rule becomes much simpler with individual executions.