Smart value - Return simple text if field does not have value

[Kelvin Teng]

I am trying to create an automation rule to comment on issue when an issue is transitioned to Done status. In the comment, automation will post the following:

TextField_A: <Value_1>

TextField_B: <Value_2>

TextField_C: <Value_3>

However, in TexField_C it does not always have a value so I would like it to specify it as None instead of blank -> TestField_C:

May I know how do I achieve this?

I've tried using the following smart values and couldn't get it to work:

{{issue.customfield_ID.value.replace("null","None")}}

{{issue.customfield_ID.replace("null","None")}}

{{issue.customfield_ID.value.replace(" ","None")}}

{{issue.customfield_ID.replace(" ","None")}}

Thanks.

[Jeroen Poismans · Accepted solution]

Hi and welcome to the Atlassian Community!

You could try and solve this with a variable an SmartValue with condition:

The variable creation looks like this:

{{if(exists(issue.TextField_C),issue.TextField_C, "None")}}

And in the UI:

In the last step I logged out the value of the variable and saw it behaved as you would expect.

Give it a try!

Jeroen

[Darryl Lee]

Hi @Kelvin Teng - I believe this should do the trick:

TextField_C: {{#if(not(exists(issue.customfield_ID)))}}None{{/}}{{issue.customfield_ID}}

[Darryl Lee]

Ha! I had a similar answer to @Jeroen Poismans :-}

[Pejman Farahi]

None of the other solutions worked except this one, thanks

[Bill Sheboy]

Hi @Pejman Farahi 

Testing a smart value for "empty" is completely dependent on the field type.  The exists test will work for some field types and not for others because they are never empty: they just do not have a value for the UI to use.

Please read all the other posts in this thread and others, and always experiment to confirm your rule works as expected for the differences of "null", "empty", "empty string", etc. for your respective field types.

Kind regards,
Bill

[Kelvin Teng]

Thank you everyone for the guidance. Managed to get it to work now.

[Bill Sheboy]

Hi @Kelvin Teng -- Welcome to the Atlassian Community!

In addition to the other answers provided...

For automation rules, at least three things impact how to supply a value when the field is considered empty:

1. what is the state of the issue, such as immediately after issue-created / cloned
2. the field type, such as text, value selection, user selection, etc.
3. has the field ever had a value previously

For the first one, newly created issues may reach rules in an unstable state due to racetrack errors, leading the entire field / smart value to be missing.  The symptom for this is often a rule error indicating the field is not present for the issue type.  The fix for that is to use the Re-fetch Issue action after the rule trigger and before performing the empty field check.

Next, the field type impacts the technique needed, because the exist() function does not work for all types.  Understanding how the fields are stored in the smart values helps to learn how to test for empty values for each type.  This is particularly tricky for nested structures, such as the Fix Version, Sprint, and similar fields.

Lastly, some field types, once ever set with a value, appear to have an "empty string" versus "null", and exists() only tests for null.  I recall defects logged for this symptom, and potential work-arounds are noted below.

Additional checks / workarounds are:

• use the changelog {{fromString}} compared to an empty string,
• concatenate a known value string to the field and test for that, or
• just try using the default value operator pipe |, such as with {{issue.Story points|0}}

Kind regards,
Bill

[Darryl Lee]

Sorry, this is totally a necropost. But I was curious @Bill Sheboy, how did you figure out/discover:

• the default value operator pipe |, such as with {{issue.Story points|0}}

I couldn't find this (of course) in Atlassian's official docs...

And I'm poking around the source for mustache.js and mustache.java but am not finding anything, but then, also I can't read code very well. :-}

[Darryl Lee]

Ugh, as usual, my rubber-ducking forced me to do a better search through docs and I found it:

Default values

If a field or value doesn't exist, it usually returns an empty value, such as {{invalid reference}}.

If you need to have a value, you can specify a default value. For example, when an "invalid reference" doesn't contain a value, you can print "Hello world" using {{invalid reference|Hello world}}.

[Bill Sheboy]

Hi @Darryl Lee 

Yes, and...over time (i.e., via experimentation) I learned the default pipe | operator does not work in all contexts...and may collapse an expression to null when used.  It also appears to not be needed (any longer) for things like {{someList.size}} as a "correct" value of 0 is now returned for empty lists.

The feature seems more artisan than deterministic at times ;^)  Or, perhaps it is not well documented when it does / does not work.

Once again, I would very much enjoy finding a BNF specification for the automation language.

Have a great day!

__Bill

[Darryl Lee]

Ooof, speaking of .size, I was recently working on a rule trying to find the # of  @mentions in a comment.

(I actually wanted to go through all the @mentions to see if one or all of them are internal addresses, which we've looked into before, but alas, I could not figure out how to concatenate all the addresses together into a variable so I could check that. I think I'm running into the global scoping issue?)

ANYWAYS, it turns out that .match still has the problem of either returning either a single match OR a list, and so I had to use this nonsense to check whether there were multiple mentions:

{{exists(comment.body.match("\[~accountid:(.+?)\]").size)}}

 So clunky.

[Bill Sheboy]

@Darryl Lee that symptom may have been caused by newlines in comment body, causing the match to halt after the first "record".  I believe the workarounds for that are to replace all the newlines before the match (and return them later, as needed).

[Darryl Lee]

Ah, newlines. A good thought, and I recently discovered that Automation's regex supposedly supports multiline and single-line modes from Java's Pattern class.

So for good measure I tried adding (?s) which should enable DOTALL mode which means the . will match line terminators (which includes newlines).

But my regex is actually doing a non-greedy (oh funny, the term is now "reluctant") search for everything up to the closing bracket, so then, newlines shouldn't even come into play, since they're not what I'm looking for.

But ANYWAYS I tried my search for .size with both (?s) and (?m) and for funsies also (?ms) and they ALL came back with the same results.

Test smart value (just showing single-line mode):

{{comment.body.match("(?s)\[~accountid:(.+?)\]").size}}

But regardless of the mode, I always got undefined instead of 1, when there was only one mention, and 2 or 3 in my tests with multiple mentions. :-{

ANYWHO though, I mention the multiline and single-line modes because in a case where you are needing to find text that may span multiple lines, or are searching for text at the beginning or end of a line, they should help.

[Bill Sheboy]

Thanks, and I seem to recall posts where those did and did-not work in Jira automation rules, given the whole "underlying implementation is based on..." thing.