JIRA Automation Action that terminates the execution

[Ryan An]

Hi,

I would request for a feature to terminate the execution, or basically prevent another action from executing.

In the automation, I want to add a new sub-task to a hardcoded Story when something else is triggered. However, I don't want it to be added if it already exists. so:

• I loop through all the sub-tasks of a hardcoded Story
  • If the summary == {{issue.summary}}
    • I want to exit the execution
• Not has been found from the previous loop, so I will add a sub-task with summary = {{issue.summary}}

I found the way to use JQL to locate all the sub-tasks to the hardcoded Story. However, it will loop through all the sub-tasks to perform something but not possible to prevent something from happening.

If I put it to pseudo-code, it would be:

for subTask in STORY.subTasks {

    if subTask.summary == issue.summary {

          system.exit()

    }

}

STORY.addSubTask(summary: issue.summary)

it could actually be better if it's possible to configure Variable in the automation. so it doesn't have to exit(), but can remember flag and use the flag afterwards.

BR

An Chin

[Ste Wright]

Hi @Ryan An 

This sounds like a condition of the rule:

• Create a sub-task unless...
• A sub-task with the parent issue's summary already exists

This wouldn't be a rule termination - but a limit of when the rule performs the action.

Could you verify if this is your need? If yes, could you provide the specifics of your rule so I can suggest a more direct solution? :)

Ste

[Ryan An]

Yeah it's one of the ways to solve it. A boolean variable would solve it too. do you have any plans to include variables? you can refer to shortcuts in iOS I think these are quite similar.

[Ryan An]

btw my company is using a non-cloud version of JIRA. how long should I expect when the update would be available to our installation?

[Ryan An]

@Ste Wright 

[Ste Wright]

Hi @Ryan An 

I don't work for Atlassian - Community Leaders are volunteers on the Community. 

I'm not sure if Atlassian are considering boolean variables within automation rules. There are few other options if you're looking for a more advanced automation options - such as a scripting app like ScriptRunner!

I can try to find a method to do it using Automation though if you can clarify the specific need you're trying to meet with the rule :)

Ste

[Ryan An]

Hi @Ste Wright 

Sorry I thought you are a developer in Atlassian. :P

Speaking of the need, in the first reply from me above I agreed what you described would be one of the solutions. Sorry if that was not clear enough. It would be even better if the user can actually configure the condition you mentioned as 2nd bulletin

"A sub-task with the parent issue's summary already exists"

so as the action on the 1st bulletin so that the user could have a wider choice of what they can do.

[Ste Wright]

Hi @Ryan An 

No worries :)

What would you like to configure as part of the condition? There are some options to customise, depending on the need!

Ste

[Ryan An]

Hi @Ste Wright ,

For now what we need is as you mentioned, but for flexibility it would be good to enable customization for this function. For example, create sub-task unless some other sub-task exists, or unless some other issue exists with JQL, etc.

BR

Ryan

[Ste Wright]

Hi @Ryan An 

Quite a lot of conditions do exist which covers some of these needs - check out rule conditions on this page

Ste

[Ryan An]

Hi @Ste Wright 

They are for other use cases, not for the scenario you or I mentioned above. Big part is missing from this scenario.

BR

Ryan

[Ste Wright]

Hi @Ryan An 

Which part is still missing?

I think the first post I made should cover the needs mentioned in the original question; or is there more to it that I'm missing?

Ste

[Ryan An]

Hi @Ste Wright 

The ability to add {conditions} prior to an {action} related to a sub-task - is missing

In my case, {condition} is {isExisted} and {action} is {skip} creating the sub-task.

In other cases, {condition} can be (as i imagine) {hasTwo}, {hasThree}, {hasNo}, {createdBefore}, {hasAttachement}, etc. and {action} can be {do create}, {changeSummary}, {changeDescription}, etc. 

It's no super urgent for me to have full-spec conditions but at least skipping is not possible as now.