nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Why am I seeing "new" returned as the statuscategory rather than "to do"

Jack Brickey

While investigating an automation rule and seeking help in the community (see post here), I came across an interesting anomaly that I could not explain. I have since found the answer and wanted to post this pseudo question so that I could actually provide the answer. The intent is to help others that might run across this in the community.

Observation

While using statuscategory() within an automation rule condition I discovered that rather returning "to do" I was receiving "new". I attempted this in a different Jira instance and did not observe this anomaly.

Screenshot 2025-03-17 at 1.37.23 PM.png

....Look to the Answer for...well...the answer.

Accepted answers

Jack Brickey

Here is the explanation

Analysis

I researched this through all of the normal channels (Community, Google, peers) without any luck. So I reached out to Atlassian support and was able to get closure. Yay!

Info back from Support (BTW hats off to them for a same day response)

<There is an open bug on this> - https://jira.atlassian.com/browse/JRACLOUD-80301

Essentially, in some places within Jira cloud's code, the "To do" category is instead named as "New", such as when querying via webhook/rest API and seeing it in the payload. In your situation, that's probably where automation is grabbing the status category name from instead of where ever else it's stored as "To do".

However, in all cases, it's essentially just a naming discrepancy where they both fall under the same exact category in itself, and should function all the same. The only time it may matter is if you're trying to use that smart value within a condition, in which case you would just set the condition up for "New" instead of "To do" in mind.

It is worth noting that in my case I am precisely interested in using the statuscategory() in a condition within my automation rule. Given that I don't really understand when this might occur I will likely build that into my conditions. That is, I will consider both "new" and "to do" in my conditions just to future proof them.

I hope that this helps anyone else searching for an answer should they come across the anomaly.

All comments

Jack Brickey

Here is the explanation

Analysis

I researched this through all of the normal channels (Community, Google, peers) without any luck. So I reached out to Atlassian support and was able to get closure. Yay!

Info back from Support (BTW hats off to them for a same day response)

<There is an open bug on this> - https://jira.atlassian.com/browse/JRACLOUD-80301

I hope that this helps anyone else searching for an answer should they come across the anomaly.

Bill Sheboy

Hi @Jack Brickey

I hypothesize racetrack errors like this are going to get "worser" before they get "better".

Today, the Issue Created trigger (or a webhook capture of that event which triggers an Incoming Webhook trigger) can fire before all of the data is available. This manifests as at least these symptoms I have observed:

the issue / work item is not fully "baked" by the time the rule starts, sometimes causing permissions and other errors that make no sense in the audit log...and a status / statusCategory of "New"...which appears to be transitory, internal value
even when the issue / work item is ready-ish, some of the fields may not be available to the rule yet.

The mitigation for these symptoms is to add the Re-fetch Issue action after the Issue Created trigger (or some other delay for the Incoming Webhook trigger before accessing the content). These symptoms seem to also happen in some cases for the Issue Moved, Issue Linked, and Issue Updated rule triggers.

Now the worser part...I have seen questions and defects perhaps indicating the changes to sunset "Epic Link" and replace it with "parent" can lead to multiple issue events firing for the same issue change! I again hypothesize this is both a racetrack and code error: rather than using the endpoint's ability to set the parent when an issue is created, it appears to happen with a second endpoint call, leading to a new event...and potentially multiple rule runs for the same person-initiated action.

Another "I wonder": perhaps the brand-new retry capability rolling out for automation rules is over zealous, leading to racetrack errors we have not even observed before. Who knows?

Kind regards,
Bill

Jack Brickey

Thanks for the insights @Bill Sheboy . I don't disagree with your concerns. It is an interesting hypothesis you pose and just for grins I may try the refetch post trigger on my observations here.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud

automation