Last updated Oct 10, 2024

Changelog

This page includes release notes and updates for app developers working against the Assets API. Use this page to keep track of upcoming changes, deprecation notices, new features, and feature updates from Assets.

Go to our developer community to ask questions. You may also be interested in the What's New blog for Atlassian Cloud where details of major changes that affect all developers are announced.

10 October 2024

Deprecation Notice Summable attribute removal from Assets REST API's

We are making the following change to the REST API’s for Assets in Jira Service Management Cloud:

We will be removing the summable attribute from the request/response payload of the following endpoints:

  1. /object (response)

  2. /objectschema (response)

  3. /objecttype (response)

  4. /objecttypeattribute (request/response)

This change will be made on or after 31 Jan 2025.

2 September 2024

Deprecation Notice Assets for Jira Service Management cloud will have a new limit of 2 unique constraints per object type

After 31st of October 2024 we will be introducing a new limit of 2 unique constraints per object type. For customers with any existing object types that already have more than 2 unique constraints, we are asking these customers to please reduce these to 2 per object type before 31st of October 2024.

More details

At present an object type in Assets for Jira Service Management can have an unbounded number of unique constraints applied to its attributes. After 31st of October 2024 we will be introducing a new limit of 2 unique constraints per object type. This is part of our effort to offer a more scalable, performant and reliable experience as we make major enhancements to the underlying platform that powers Assets. We believe this new limit will be sufficient for the vast majority of use cases in which Assets is utilised.

For customers with any existing object types that already have more than 2 unique constraints, we are asking these customers to please reduce these down to 2 per object type before 31st of October 2024. Not doing this will mean:

  • When we are ready to begin moving you to the new Assets platform, we will be unable to do so without first disabling your unique constraints on any object type with more than 2.

  • You will be able to re-enable up to 2 per object type after this is completed.

More information on this process will be released in future.

Effected public Assets REST API endpoints are:

Both of these endpoints will begin to return a HTTP status code of 400 if there is an attempt to add a unique attribute constraint (via the uniqueAttribute property) and the limit has been reached.

If you have more than 2 attributes on an object type that you need to ensure are unique, a potential workaround is creating an automation rule to check the number of objects that can contain a particular value after an object is updated. You could then raise a Jira issue to resolve the duplicate or notify the relevant schema administrator.

By making these changes we can ensure your site can begin to utilise our improved Assets platform when it is completed and reap the vastly improved the scalability, performance and reliability it will offer. We’ll be announcing more about this soon.

21 August 2024

Announcement Additional IP ranges for Atlassian Cloud

We're announcing new IP ranges that will soon be available for requests from external clients, such as browsers and API integrations:

  • 13.35.248.0/24

  • 13.227.180.0/24

  • 13.227.213.0/24

These ranges won't be used to make outgoing connections from Atlassian Cloud to remote systems, for example, webhooks.

More details

To prepare for this change, update your firewalls and other security measures to allow connections to the new IP ranges.

For more information, see IP addresses and domains for Atlassian Cloud products, which includes instructions on how to receive notifications of changes, as well as links to machine-readable lists of our IP ranges.

16 August 2024

Deprecation Notice Assets for Jira Service Management cloud will have a new limit of 120 attributes per object type

After 30th of September 2024 we will be introducing a new limit of 120 attributes per object type. For the few customers with any existing object types that already have more attributes than this new limit, we are asking these customers to please reduce these numbers down to no greater than 150 per object type before 30th of September 2024.

More details

At present an object type in Assets for Jira Service Management can have an unbounded number of attributes. After 30th of September 2024 we will be introducing a new limit of 120 attributes per object type (which also includes any attributes inherited from a parent object). This is part of our effort to offer a more scalable, performant and reliable experience as we make major enhancements to the underlying platform that powers Assets. We believe this new limit will be sufficient for the vast majority of use cases in which Assets is utilised.

For the few customers with any existing object types that already have more attributes than this new limit, we are asking these customers to please reduce these numbers down to no greater than 150 per object type before 30th of September 2024. If you are one of these customers we’ll be reaching out to you to see if we can help in any way.

By making these changes we can ensure your site can begin to utilise our improved Assets platform when it is completed and reap the vastly improved the scalability, performance and reliability it will offer. We’ll be announcing more about this soon.

Deprecation Notice Assets for Jira Service Management cloud will have a new limits on URL, Email and Select attributes

After 30th of September 2024 we will be introducing new limits regarding URL, Email and Select attributes. The limits are:

  • A maximum cardinality of 50 for attributes with multiple values, OR

  • A total of no more than 2700 characters for all values within an attribute (single or multiple values)

Whichever is reached first.

For Select attributes these limits apply to both attribute values and options.

For the few customers with existing data that breaches this limit, we are asking these customers to please adjust their data to align with the limits by 30th of September 2024.

More details

After 30th of September 2024 we will be introducing new limits regarding URL, Email and Select attributes. The limits are:

  • A maximum cardinality of 50 for attributes with multiple values, OR

  • A total of no more than 2700 characters for all values within an attribute (single or multiple values)

Whichever is reached first.

For Select attributes these limits apply to both attribute values and options.

For example this would mean that if a URL, Email or Select attribute had 50 values, then each value can on average contain 54 characters.

This is part of our effort to offer a more scalable, performant and reliable experience as we make major enhancements to the underlying platform that powers Assets. We believe these new limits will be sufficient for the vast majority of use cases in which Assets is utilised.

For the few customers with existing data that breaches this limit, we are asking these customers to please adjust their data to align with the limits by 30th of September 2024. If you are one of these customers we’ll be reaching out to you to see if we can help in any way.

By making these changes we can ensure your site can begin to utilise our improved Assets platform when it is completed and reap the vastly improved the scalability, performance and reliability it will offer. We’ll be announcing more about this soon.

15 July 2024

Deprecation Notice ID's in the REST API for Assets in Jira Service Management cloud will be transitioning from numeric to UUID

"id" fields in the various entities of the REST API for Assets in Jira Service Management cloud are of type string. Despite being a string, many of these contain a numeric value (for example "1245"). Please note that after the 30th of September 2024 some Asset entities will begin to be assigned a UUID value (for example "11ace219-a427-405c-bbb5-61d4f958e3fa") instead of a purely numeric one. If you have already treating these values as strings as per the API specification then you will not be effected by this change. If you have been assuming a numeric value within "id" fields, please make the appropriate adjustments to accomodate UUID’s before 30th of September 2024.

Note: despite all Asset entities being assigned a new UUID for the "id" field, the numeric values will continue to work as they do today when querying existing data via the publicly documented REST API’s. There is no need to update any id’s you might have previously stored in order to query particular data. This will be a backwards compatible change.

More details

If you have already treating these values as strings as per the API specification then you will not be effected by this change. If you have been assuming a numeric value within "id" fields, please make the appropriate adjustments to accomodate UUID’s before 30th of September 2024. Id’s on existing entities will continue to be queryable via their numeric id to maintain backwards compatibility.

10 July 2024

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

AQL in Assets for Jira Service Management cloud supports queries on Status attributes using the Name of the Status. For example Status = ACTIVE

An 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.

More details

If you are using Status ID’s in your AQL queries, please adjust these to use the Status Name instead before the 30th of September 2024.

30 June 2024

Added Added JWT authentication support for Assets

30 May 2024

Deprecation Notice Upcoming changes to AQL in Assets for Jira Service Management cloud

We have some important updates to share regarding AQL in Assets for Jira Service Management in cloud. A number of features are being deprecated or changed in order to allow us to greatly increase the scalability, performance and reliability we can offer our customers. These changes will apply to any of our public API endpoints that accept AQL as a parameter. Please see below for more details or join the discussion on our Atlassian Developer Community post https://community.developer.atlassian.com/t/upcoming-changes-to-aql-in-assets-for-jira-service-management-cloud/80409.

All changes listed come into effect on or after 30 Sept 2024.

More details

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 trying LIKE to search for IP addresses in a particular range, e.g.
"IP Address" LIKE "192.0.0"
However, we do understand in many cases this will not be a suitable workaround.

TextArea attributes will no longer be searchable with AQL or other Assets search experiences

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.

The behaviour of ordering on User, Group, Project, Bitbucket repository and Opsgenie team attributes is changing

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 of AQL results by attributes with a maximum cardinality greater than 1 will not be supported

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.

Greater than and less than operators will only be supported on numeric and date attribute types

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.

Nested use of the connectedTickets() function within inboundReferences() and outboundReferences() functions will not be supported

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.

Using dot operator(.) in the context of an import mapping will not be supported

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.

14 May 2024

Deprecation Notice Changes to Assets /object/aql and /object/navlist/aql endpoints

We are making changes to the /object/aql and /object/navlist/aql endpoints within the REST API’s for Assets in Jira Service Management cloud.

  • We will be removing the total attribute from the response payload of the /object/aql endpoint. If you require this, instead use the /object/aql/totalcount endpoint which will provide a total count for any AQL query.

  • We will be removing /object/navlist/aql from our list of supported public endpoints and it should now be considered deprecated. Instead we recommend you migrate to the /object/aql endpoint.

These changes will be made on or after 30 Sept 2024.

18 April 2024

Deprecation Notice Object attribute value ID will be removed from all Assets REST APIs

We are making changes to the responses of a number of endpoints within the REST API’s for Assets in Jira Service Management cloud. These endpoints include in their response body the ID for an object attribute value. This ID is now deprecated and will be removed (see https://community.developer.atlassian.com/t/object-attribute-value-id-will-be-removed-from-all-assets-rest-apis/79259 for details of all effected publicly documented endpoints).

This change will be made on or after 30 Sept 2024 for our publicly documented API endpoints. For any undocumented API endpoints that include this ID in their response body the change will be made sooner, on or after 1 Jul 2024.

18 March 2024

Deprecation Notice The Jira Service Management Assets api endpoint GET /aql/objects is deprecated and will be removed after 18th of September 2024

The Jira Service Management Assets REST API endpoint GET /aql/objects is now deprecated and will be removed after the 18th of September 2024. For querying Assets objects please move to the API endpoint POST /object/aql.

More details

You should now use the endpoint POST /object/aql for all AQL queries to Assets in Jira Service Management.

24 January 2024

Deprecation Notice Assets AQL function anyAttribute to be retired at end of March 2024

We are deprecating the Assets AQL anyAttribute function and it will be retired on 31st March 2024. For further details see https://community.atlassian.com/t5/Jira-Service-Management-articles/UPDATED-DATE-Upcoming-change-Assets-AQL-function-anyAttribute-to/ba-p/2586178.

27 November 2023

Added Added new functionality to Imports REST API in Assets

Added externalIds functionality to object schemas, object types and object type attributes. externalIds allows users to assign an Id to an object schema, object type, and object type attribute for future modifications, and as a unique reference in update and mapping requests.

https://developer.atlassian.com/cloud/assets/imports-rest-api-guide/schema-and-mapping/

https://developer.atlassian.com/cloud/assets/rest/api-group-importsource/#api-group-importsource

More details

Added extra fields to support:

  1. uniqueness

  2. cardinality

  3. status

  4. externalId

Added a new endpoint which retrieves the JSON provided in the mapping endpoint:

  1. Get /schemaAndMapping

18 September 2023

Deprecation Notice Assets API Deprecations to IdAsInt for ObjectSchema Responses

We will be making changes to Assets ObjectSchema REST API. In March 2024 we will be removing idAsInt property from the ObjectSchema API response payload. We have updated the examples in our documentation to reflect the future state of the response payload, without the idAsInt property.
Currently, our identifiers (id or <entity>Id) are strings representing integers, but they may change to UUID or other string representations in the near future.

Rate this page: