Change order of subtasks.

[Douglas Oliveira]

Hi everybody,

In my jira i have five types of tasks, and ten types of subtasks, Each task have a different order of subtasks when they are created.

When i change the type of task, i created a automation for to eraser all subtasks and to create new subtasks in correct order, but i need of more precision in this action.

The same subtask is in different subtask and I want it to:

1. When to change type of task excluded the subtasks, that will not be used;
2. When havent the subtasks that was need, create it;
3. Put the new subtasks created in a correct order with the others.

For exemple:

Task 1:

• Registration
• Production
• Revenues
• Send
• Instalation
• Measurement

Task 2:

• Negotiation
• Registration
• Production
• Revenues
• Send 
• Measurement

When i change Task 1 to Task 2 :

• Negotiation (Created and put in order)
• Registration (Keeps)
• Production (Keeps)
• Revenues (Keeps)
• Send (Keeps)
• Negotiation (Excluded)
• Measurement (Created)

Somebody know how i can create this automation?

The most problem is to put the subtasks in a new order.

[Bill Sheboy · Accepted solution]

Hi @Douglas Oliveira 

Short version: I do not believe that is possible with out-of-the-box automation

Longer version: 

• There are several open defects and suggestions related to ordering of sub-tasks, such as this one: https://jira.atlassian.com/browse/JRACLOUD-42231
• My understanding is that sub-task ordering within the parent is based upon the create date/time...unless you change it with the UX
• I haven't tried this: A possible work-around for automation would be to introduce delays and attempt to add them in your order.  For example, add each sub-task, one-by-one, with separate actions followed by a re-fetch action.  That will dramatically slow down the rule (eating up your automation time limits) but it may fix the ordering.

Kind regards,
Bill

[Douglas Oliveira]

I @[deleted] , Thanks for the anwser.

Well... I imagined that to put the subtasks in order was the most dificult, the organization of the subtasks have some limitetions in the Jira.
But is very interessant your understanding, I thought that the Jira organize the order of subtasks only by key numer.
By the way do you know a way for the automation to search a subtasks when i change the type of task and if doesnt to find them, creat them?

Best regards,
Douglas

[Bill Sheboy]

Regarding ordering, as sub-tasks are created over time the issue keys will increase.  So key order matches created order.

For your next question, would you please explain a bit?  Are you asking how to find if a sub-task exists with some criteria, and when not found add one with that criteria?

If so, you could use Lookup Issues with JQL, and if the resulting count of issues is zero, create the issue.  The JQL would be something like:

project = myProject AND issueType = Subtask AND parent = parentIssueKey AND some other criteria

And the condition check would be {{lookupIssues.size|0}} equals 0

[Douglas Oliveira]

@Bill Sheboy 

For exemple, i have this standarts of tasks and subtasks:

Task1:

• Registration
• Production
• Revenues
• Send
• Instalation

Task 2:

• Negotiation
• Registration
• Production
• Revenues
• Send 
• Measurement

Task 3:

• Negotiation
• Registration
• Production
• Revenues
• Send 
• Instalation

When i change the type of issue, the automation should to create the subtasks for keeps the standart but cant to have duplicate subtasks. Not necessarily in the same order, i can change this after.

[Bill Sheboy]

Thanks for clarifying;

• there are overlaps between your standard Sub-task sets (e.g. Registration), and
• when you change Task types,
• you want to add/remove the delta changes, and
• have them appear in the desired order

Correct?

If so, the only way I am aware of to do that would be to delete (or abandon/complete) the existing sub-tasks and then add them back, one by one, with the delay I noted, in order to force the ordering.

This will lose any information in the overlaps which was manually entered (e.g. Registration sub-task details)

If we may, let's back up a bit: why, when, and how often would a Task type change?  What is your business workflow that needs this?

For example, let's say a Task is created and can change type *before* work begins.  In that case, It may be better to not add the sub-tasks until work begins (based on status transition).  This would eliminate the need to change sub-task lists later.

[Douglas Oliveira]

Hi @Bill Sheboy , thankyou again.

Lets me explain, We have some types of project and for to know what the type is corret we need of a feedback of client, but have some subtasks that is the same for all projects. This is happens with a few frequency, i can put the subtasks of manual way, but this could generate delay some process because Would have to wait for me to see and modify.
If i have a automation for this i can create some triggers for change the type of project (a email received for exemple), making things more fluid.   

Well, we wanna a process that be most automate possible, but put the subtasks in order really seems  dificult, Then i thinked in have a automation for delete the subtasks that are not needed and create the ones I need, When I change a tpe of project.

not necessarily leaving them in order. i do this manually after.
But the difficulty now is create a automation that When i change the type of project, create a subtask if it doesn't exist

[Bill Sheboy]

Douglas, regarding your last sentence:

But the difficulty now is create a automation that When i change the type of project, create a subtask if it doesn't exist

I believe the only way to do that is to perform a JQL check for the sub-task with that summary and parent, check for its presence, and add it when missing.  The presence check would be with an if/else block and related issues condition, or using Lookup Issues with JQL and testing for no issues found: {{lookupIssues.size|0}} equals 0

[Douglas Oliveira]

Hi @Bill Sheboy ,

I am trying to use the JQL search, but i am doing something wrong, i used this rule.

you could help me with this rule?

[Douglas Oliveira]

Sorry, the picture isn't good

[Bill Sheboy]

Hi, Douglas!  A few things I noted in your rule images:

1) In your condition you are testing Lookup Issues information, but you have not used the Lookup Issues action.  That needs to happen first to load up the data with a JQL statement to look for any missing sub-tasks.

2) In your condition JQL, there are a few issues:

• you compare to the entire trigger issue rather than the key: parent = {{triggerIssue.key}}
• it appears to have some stray quotation marks around AND
• JQL is not a SQL, and so you cannot include lookup issues on the left side of an expression

[Douglas Oliveira]

Thank you  @[deleted] ,

I dont knew this action function, very usefull.

But doesnt worked, I belive that have something wrong in my smart value, I am use:

{{lookupIssues.issueType.Aceite do cliente.size|0}} = 0

Is the correct way ?

Regards,
Douglas

[Bill Sheboy]

Douglas, you cannot query with lookup issues that way.

How about this: Let me try to draft a rule for what I believe you are doing, and you can provide ideas to improve it.

• trigger: issue type changes
• condition: issue type is your Task 1 type
• branch: for the sub-tasks
  • condition: issue-type is not one of the valid sub-tasks for Task 1
  • action: delete this sub-task
• action: lookup issues with JQL of...
  • parent = {{triggerIssue.key}} AND issueType = your sub-task type
• if/else
  • advanced compare condition: the sub-task was not found
    • value 1: {{lookupIssues.size|0}}
    • condition: equals
    • value 2: 0
  • action: add the sub-task of the desired type
• Repeat the action lookup issues and if/else for each type of sub-task you want to add

Please compare this to your rule and modify as needed for your issue type values.

[Douglas Oliveira]

Thank you @Bill Sheboy ,

Its worked! But i dont know why doesn't worked with the smart value {{lookupIssues.size|0}}, Its worked when i use  {{lookupIssues}}.

I really appreciate it. Will help me a lot!

Best Regards,
Douglas