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; } } }

Has JQL status value become case sensitive recently?

Pierre Ibrahim

For the longest time, I could do a jql of "status = CANCELLED" or "status = Cancelled" and both would return the same amount of rows, however this morning after the Cancelled status's name was erroneously changed, I changed it back to the original value from the audit log (Cancelled), and doing a JQL of status = CANCELLED yields no results, however status = Cancelled works fine.

Accepted answers

Aaron Pavez [ServiceRocket]

Hi @Pierre Ibrahim

Yes, the reindex its a painpoint with any changes to anything that has a lot of work items attached to that change.

It might take some hours depending on that.

Regards, Aaron

All comments

James Gamble

Hola Pierre,

I don't think this is an intentional change that makes status values generally case-sensitive. What is interesting about your case, however, is that the behavior started immediately after that Status was renamed and then changed back.

I couldn't find a Jira Cloud release note documenting a change to JQL case sensitivity, and Atlassian's current JQL documentation still uses Status = open as a valid example. That makes me lean toward the rename being the trigger rather than a new JQL rule. I'd try the status ID as a quick test. Jira supports querying Status by either its name or its numeric ID. You can get the ID from /rest/api/3/status and then try: Status = 12345

If that returns the expected issues, while Status = CANCELLED does not and Status = Canceled does, then the issues themselves are still associated with the correct Status, and this is specifically name-matching after the rename.

There is also an existing Atlassian issue in which renaming a status can break JQL filters that reference the Status by name. It isn't the same symptom you're seeing, so I wouldn't call it the same bug, but it does show that status renames and name-based JQL have known rough edges. Atlassian's workaround is also to use the status ID.

I'd also test an unrelated status without renaming it, for example, Status = "IN PROGRESS" versus Status = "In Progress". If both work, that would pretty strongly isolate this to the Canceled Status and its rename history, rather than to a Jira-wide change in case sensitivity.

Thanks,

James

Pierre Ibrahim

Hi James,

Surprisingly enough, I now get the same number of rows with Cancelled vs. CANCELLED. Guessing JIRA needed some time to index?

Aaron Pavez [ServiceRocket]

Hi @Pierre Ibrahim

Yes, the reindex its a painpoint with any changes to anything that has a lot of work items attached to that change.

It might take some hours depending on that.

Regards, Aaron

Welcome!

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

Quick Links

Find more posts tagged with

jira

cloud

jql