Hello Atlassian Community,
We have some important updates to share regarding AQL in Assets for Jira Service Management in cloud.
We're in the process of making fundamental improvements in performance, scalability, and reliability for Assets in Jira Service Management. We’ve set ourselves some ambitious goals which will bring huge improvements for all of our customers. As a part of this effort, we’ve determined that some of the AQL features we offer today will not perform or be reliable enough in their current form - thus hindering our ability to create the Enterprise-grade platform we want to provide you. Due to this we are deprecating some features and changing the behaviour of others. Based on your feedback, we will explore returning some of these in future in a form that allows us to meet the performance and reliability standards you expect from us.
All changes listed below come into effect on or after 30 Sept 2024 and will apply to use of AQL in our user experiences and public API endpoints.
Removal of the CIDR function
The CIDR function allows filtering over IP ranges, for example
"IP Address" IN CIDR("192.0.0.0/8")
If this is a form of search you require, as an alternative we suggest using LIKE to search for IP addresses in a particular range, e.g.
"IP Address" LIKE "192.0.0"
Not to be confused with Text attributes which will continue to be searchable as they are today. If you have information contained with a TextArea attribute that you need to search on, we recommend moving it into one or more Text attributes.
Ordering via the Assets user experience or by using an AQL ORDER BY
will no longer have the same behaviour for attributes of type User, Group, Project, Bitbucket repository and Opsgenie team. Ordering will be based on the underlying ID of the attribute value as opposed to the visible name. We understand this will likely not be the behaviour most of you expect in this situation. For most customers the new behaviour will appear as “grouping” as opposed to “ordering” as the underlying ID is not visible but values with the same ID will appear together after ordering. Ordering by all other attribute types will continue to work as they do today.
Ordering via the Assets user experience or by using an AQL ORDER BY
will no longer be supported for attributes with a maximum cardinality configured as greater than 1. Currently very few customers use ordering on attributes of this kind and the behaviour often does not match what our customers expect. Ordering will continue to be supported on all attributes with a maximum cardinality of 1.
Today it is possible to use the >
, >=
, <
, <=
operators on attribute types where this is typically not required. Use of these operators will be limited to Integer, Float, Date and Date time where the use case and expected behaviour is clear.
The connectedTickets()
function will not be usable when nested within the inboundReferences()
or outboundReferences()
functions. This means an AQL query such as
object HAVING connectedTickets(labels is empty)
(i.e. objects connected to issues where the label field is empty) will continue to behave as it does today. However,
object HAVING inboundReferences(object having connectedTickets(labels is empty))
(i.e. objects with an inbound reference from other objects which are connected to issues where the label field is empty) will not be valid AQL.
Use of the dot operator(.) will not be possible when using AQL as a part of mapping source data to an object in an import configuration. This restriction will apply only to the use of AQL in the import mapping section of the Assets import experience as well as the import endpoints in our public REST API. In all other locations the the dot operator(.) will continue to function as it always has.
While we have assessed that most of these changes will have a low impact on the majority of our customers, we understand that for some of you this may not be the case and we apologise for any disruption this may cause you. 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
Justin King
Senior Product Manager, Jira Service Management
14 comments