Dear hive-mind, can you kindly help me on this issue?
Target situation:
Approach:
Thank you most kindly!
Timon
Hi @Timon Karge-Lücker -- Welcome to the Atlassian Community!
Sorry for the long answer, as I have also spent lots of time on this automation behavior of determining emptiness. I will add bolded text to help focus the ideas I suggest.
First thing, are you using Jira Cloud, Server, or Data Center version, as automation rule behavior is different for the different app versions? Your post seems to indicate Cloud, but that linked documentation you noted is for Server / Data Center. Here is the one for Jira Cloud automation: https://support.atlassian.com/cloud-automation/docs/jira-smart-values-text-fields/#isEmpty--
The isEmpty() function works for text fields, and few others. Additionally, I have found testing for "empty" or "blank" to vary in behavior based upon field types. Experimentation is often required to determine what will work for testing values with isEmpty() and other methods. Note that distinction I made between "empty" and "blank", where one is a null value and one is a zero-length string. And so things like conditional expressions could collapse when a smart value is null, leading to no result, true, false, or otherwise: it is just null.
Some fields, once set to a value and then later cleared, appear to never be null again: they are instead "blank" or in some other state. The workaround for this is to concatenate to a known value, remove that value, and then test the length of the resulting text for zero.
Context is important for automation rules. You do not show your rule(s), and it may be possible that some fields are empty because the smart value, or issue, does not exist at that rule scope. Writing to the audit log can help to confirm this.
Without seeing your rule, I cannot tell if you are using any iterators or list fields (e.g., Sprint, multiple select option, etc.). Inside of an iterator, the community has observed symptoms of conditional logic errors for list fields, where the wrong values are returned. The workaround for that is to fully expand the iterator and list values into a created variable first, and then use either conditional logic or the match() function.
For your specific examples shown, I see some extra curly brackets inside of the conditions, such as the one below. Try removing the extra brackets once inside of the conditional logic.
{{#if(equals({{issue.fields.timetracking.originalEstimateSeconds}}, "0"))}}
Original Estimate is empty
{{/}}
Finally, the values for some smart values appear to be dynamically determined by additional REST API calls. (For example, the content of subtasks.) These may also collapse to null when used with functions, particularly withing conditional logic expressions. My recommendation is when something that looks like it should work does not work, save the field to a created variable first and then try the condition.
Kind regards,
Bill
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.