Jira automation variable value set to empty

[Peter Reiser]

How can I set a Jira automation variable to empty ? 

When adding a variable I have to provide a value.

The current workaround is to set the value of the variable from an empty custom field.

-- but this is not a really professional solution :-)

Thanks your your feedback

Peter

[Johnny Hermann · Accepted solution]

One workaround:

1. Create the variable with a value that is an arbitrary known string:
   • Variable name:  myCoolVariable
   • Smart value:  _EMPTY
2. Set ("create") the same variable again with a value that is itself with the "remove" function called on the same arbitrary known string:
   • Variable name:  myCoolVariable
   • Smart value:  {{myCoolVariable.remove("_EMPTY")}}

[micagl admin]

works just for the first if/else block, if you have another one afterwards, it won't work for this

I don't know why... and it doesn't matter where your define the "global" variable, e.g. right at start or after the first if/else block -> it is still the same

[Jorge Martinez Bonilla]

We used {{NULL}} when assigning the variable. The constant is documented in Jira Smart Values - Math Expressions

[Steven Tonge]

You can just use {{remove}} to empty a field.

[micagl admin]

that is basically another variable of name "remove", if this one is not set, it will probably work, but I guess not a good idea, until someone defines this variable as it won't be empty anymore and probably break the entire rule and nobody knows why...

[nmenere]

Hey Peter,

I'd love to hear the use-case for this as I can't really think of one.

Cheers,
Nick Menere
Automation Group Product Manager

[Peter Reiser]

@nmenere  Here is our use case

1 .We have a 1st level Servicedesk per country ( 10+ Servicedesks)

2. Each Country Servicedesk has different values for the Technical/Application categorisation as they have different services/applications

3. We have automated ticket routing for 2nd level support Servicedesk's based on cascading fields (Technical/Application categorisation) from the 1st Level Servicedesk.

We are using Automation rules to evaluate the Technical/Application values and then set to correct Technical/Application categorisation for the 2nd level Servicedesks. In certain case we have to set the cascading field to empty

Example:

{ 
"fields": {
"customfield_10052" : { "value": "Services", "child": { "value" : "{{TechnicalCategory}}"} },
"customfield_10051" : { "value": "{{ApplicationCategory}}", "child": { "value" : "{{ApplicationCategoryChild}}"}}
}
}

Where variable {{ApplicationCategoryChild}} has to be empty

[Johnny Hermann]

I have a scenario where I need to check if any of a set of possible changes occurred during an Issue Updated event.

I need to create a variable defaulted to empty / null.  Then with a sequence of if-elseif-elseif, if any branch is true it sets the variable to a non-empty value (like "true").  Then the rule is allowed to proceed only if the variable is not empty.  (I need to use if-elseif because Automation does not provide logical "OR".)

Workaround:  Check the variable for exactly "true" (or not "false").  but "code" not as "clean".

[Patrick van der Rijst]

Scenario: we have a transition screen where you can check boxes like "Create Epic for this work"

Within the automation rules we create various issues and based on if an epic is created, set that as the epic link.

Since we can't do an if within an if, I can't check if the epic is created and should be linked so I have created that as a global variable and setting that variable within the block of the epic creation.

[jshippy]

I do an issue lookup to sum up the values of a field.
I store that sum up in another variable.

I do another issue lookup to target a specific issue to deposit the result. I attempt to edit the target of the issue lookup, but Jira ends up editing one of the issues from the FIRST {{lookupIssues}}. Seems like subsequent Issue lookups ADD to the existing {{lookupIssues}} instead of replacing them. 

I'd prefer to null the field out before doing another issue lookup.

Scratch this, it was underdocumented behavior of the "Edit Issue" automation.