Has there been changes to JQL operators?

[Tobias H]

Hello!

All of a sudden, my automations that are configured to respond to ""Request Type" = "<Type of Request>" has suddenly stopped working with the message:

The operator '=' is not supported by the 'Request Type' field.

The same automations ran perfectly fine and executed as intended on the last of June, but today all of the sort has the same error.

I've also tried using other operators to get it working, but to no avail.

Anyone that has any insight, or change notes to point to?

---

Update from Atlassian Support on cause of issue:

I investigated and was able to identify the issue causing the JQL to break. You are hitting a similar known bug:

Creating a custom field the same name with a system field breaks JQL that relies on the system field

To provide context, when there are custom fields (either global or team-managed) that have the same name as the system fields like "Request Type", it will break the JQL for the system "Request Type" field. This can only be replicated if the user executing the JQL has access to the project using the same custom field name.

[Nic Brough -Adaptavist- · Accepted solution]

One obscure thing to check.

Go to a search and blank out the current one, then start typing.  Do not copy and paste, start typing Request Type.  Jira will start trying to autocomplete after the first few letters, so when it gets down to fields starting with request, is there only one Request Type on offer?

[Tobias H]

Hi Nic!

I've already tested doing advance search completly fresh as well. There are a three fields to choose from, but the one that is tied to JSM is "Request Type - cf[10601]"

Choosing it and adding a = starts listing the results of our actual request types.

Selecting one of them gives the green checkmark inside of the JQL field, but searching with any request type selected gives the error:

Have reported this to support already, so hopefully it will be resolved soon🤞

[Nic Brough -Adaptavist-]

I'd be strongly tempted to rename the other two.   Just add a . to the end of the name or something.

[Tobias H]

I'll look into it, I believe they were created by Developers who used to be admins before we tightened up the security of our Atlassian suite, and far before we purchased JSM.

Don't want to break anything for someone else while trying to fix our service desk automations 😆

But will try it if it seems safe 👍

[Nic Brough -Adaptavist-]

Yep, completely understand.  I would probably

Wait until a quiet time, after hours or a weekend

• open up the admin section for the two custom fields in separate tabs or windows (By the way, I think "Request type" is from a team-managed project, so you'll need to find which project it is in to edit it)
• open a third with your search open and ready to run
• Add a "." to the end of the names of the two fields (actually, I'd add .. to one of them, so that they're all definitely unique)
• Run the search, note the results
• Take the .s of the end of the field names, put them back the way they were

That minimises all the risks of testing - the only thing a name change might break is saved filters, and if no one is actively using them, when you put the names back, you won't have broken any of their searches.

[Tobias H]

Seems like you were on to something.

The support got back to me and said they were able to replicate it once they were added as admin for multiple of the projects using "Request Type" as a custom field.

---

Leaving the response here if someone else finds this thread with a similar issue:

I investigated and was able to identify the issue causing the JQL to break. You are hitting a similar known bug:

Creating a custom field the same name with a system field breaks JQL that relies on the system field

To provide context, when there are custom fields (either global or team-managed) that have the same name as the system fields like "Request Type", it will break the JQL for the system "Request Type" field. This can only be replicated if the user executing the JQL has access to the project using the same custom field name.

[John Funk]

Definitely good to know and thanks for posting. And I would STRONGLY let people know to NOT create multiple custom fields with the same name or the same name as system fields. I see that with Start date a lot. 

[Nic Brough -Adaptavist-]

Older versions of Jira would not let you create fields with duplicate names.  I wish Atlassian would re-implement that.

Although it would be inconvenient for team-managed projects, it would be a delight for those of us who have to clean up the mess made by allowing it.  If it were up to me, I'd also add a rule that disallows any use of the word "status" in a custom field name.

[Rilwan Ahmed]

Hi @Tobias H ,

Go to menu --> Filters --> Advanced issue search.

Run the same JQL and see if it works. I tried an example JQL "Request Type" = "Get IT help (ITSM)" and it is displaying the results. 

Also I added the automation rule and it did work without any issues.

 

Please check the rule audit log to see if someone had changed the rule. 

[Tobias H]

Hi Rilwan!

I did try it in Advanced issue search and the error about = being the wrong operator appears there as well.

Here's an image of the "Validate query":

And here's the same in Advanced Issue search:

Both of these screenshots were grabbed just now, so the issue still exists on my end 😓

Here's a screenshot of when it worked on Friday vs the failure today:

There hasn't been a config change on the rule since end of May, when I created the rule.

But if this issue is only on my end, I'll reach out to Atlassian support instead.

Thanks for the help! 😊

[Rilwan Ahmed]

As @John Funk  told earlier, its better you contact Atlassian support. I could not find anything related to Request type JQL operators in Change log

https://confluence.atlassian.com/cloud/blog 

[John Funk]

Ah! That's probably your problem then - you are probably getting crossed with the short text field which requires you to use ~ and not =

Try using the Customer Request Type field. 

[John Funk]

Hi Tobias,

I would open a support ticket to try to get to the bottom of it. 

https://support.atlassian.com/contact/#/

[Tobias H]

Yeah, it seems like that is the best way to go about it. Just wanted to check if I had missed any changes to the JQL language before that😅