AQL in Assets for Jira Service Management cloud will no support matching ID's on Status attributes

Hello Atlassian Community,

We have an important update to share regarding AQL for Assets in Jira Service Management cloud.

AQL supports queries on Status attributes using the Name of the Status. For example Status = ACTIVEAn undocumented feature also allows the same query using the ID of the Status as opposed to its Name. For example Status = 1. However, as all Status Names are guaranteed to be unique within Assets, there is no benefit to using the ID.

We will be removing this undocumented feature after the 30th of September 2024. If you are using Status ID’s in your AQL queries, please adjust these to use the Status Name instead.

We believe this change will have little to no impact on most customers. As always please reach out to us if you have any concerns or feedback.

All the best,

Justin King
Senior Product Manager, Jira Service Management

6 comments

Eglė Kaziulionytė
Contributor
July 14, 2024

ID is a more stable attribute than name. Same with custom fields. What if the administrator changes the name?

Like # people like this
Justin King
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
August 16, 2024

Hi @Eglė Kaziulionytė. You are correct that this would require a change in the AQL and I understand that it could be disruptive. Do you foresee this happening regularly? 

Jordi Garcia
Contributor
November 12, 2024

Just came here because we had automations starting to silently fail because of this.

If this undocumented feature wasn't breaking anything else I'm not sure why to remove it if allows extra flexibility.

We also use IDs instead of names as much as we can to account for changes. The problem is knowing where all these are used in automations in or outside Jira. Using the ID is much more stable and permanent than a name, even if that name is unique.

We don't expect to change this often, but when they do it will be very disruptive to maintain while the ID is much more resilient.

We would appreciate if this could be reinstated...

Justin King
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
November 12, 2024

Hi @Jordi Garcia

I'm sorry you were disrupted by this. The reason we are removing this is that the underlying implementation of AQL is changing as part of https://community.atlassian.com/t5/Jira-Service-Management-articles/Assets-for-Jira-Service-Management-Cloud-is-getting-bigger/ba-p/2838687. Maintaining some undocumented quirks like this can be problematic and cause performance impacts. 

Raphael Mateus das Neves
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
November 13, 2024

Same issue here, our rules started to break and generate hundreds of tickets. Since there is no other option I am rewriting the stuff, its not a lot so whatever. 
But two requests from this situation:
- If something similar happens in the future, would it be possible to automatically notify the rule owner via email (it should be possible to detect the pattern that is deprecated quite easily) as we do not have dedicated Jira admins that have the time (or need) to read the dev blog actively? It was great to have it in the first place because finding the issue through Google was made significantly simpler, but targeted, proactive communication would be even better.

- Would it be possible to reintroduce the pattern properly (for example via `status.id NOT IN (19, 20, 28)`)?

We fear not only administrative oversights, but also we have some translated status and some that are only German. My browser is english and my system is german. The Atlassian cloud server is likely english. So what name of the status do i use? German or english? What if i only change either? What if i change our company accounts default language?

Thanks in advance and kind regards, Raphael

Jordi Garcia
Contributor
November 13, 2024

Thanks @Justin King can we maybe request this as a new feature? I know that feature requests take years to get implemented, but at least we get the request moving.

Certainly there should be an aim to provide IDs instead of text strings in order to operate with automations and API.

Comment

Log in or Sign up to comment
TAGS
AUG Leaders

Atlassian Community Events