Changelog

Previously Jira and Confluence Cloud APIs silently discarded any body included with a HTTP GET request and continued to process the request as normal. Unfortunately, AWS Cloudfront will actively reject such requests:

https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/RequestAndResponseBehaviorCustomOrigin.html#RequestCustom-get-body

If a viewer GET request includes a body, CloudFront returns an HTTP status code 403 (Forbidden) to the viewer.

HTTP clients (other than browsers) that attempt to include a body with a GET request will observe a HTTP 403 response code, with text like the following:

Unfortunately, it is not possible to configure Cloudfront to preserve the existing silent discard behavior which previously allowed these malformed requests to be successful.

To resolve the issue ensure that your HTTP client code for your API integration does not include any body with its GET requests. These are never necessary and were previously discarded.

We have found that some developers are not even aware their program or script is including a body with a GET, and the most common body payloads are as follows:

If you observed the aforementioned error in your browser then the underlying cause is different, as browsers do not send GET requests with a body.

Please contact Atlassian Support, and ideally include the full text of the error, including Trace ID, and a HAR file covering the error:  https://confluence.atlassian.com/kb/generating-har-files-and-analyzing-web-requests-720420612.html  

In the interest of performance, we will be removing support for the objectAttributeExists attribute from the ObjectTypeAttribute response payload and the removable attribute from the ReferenceType response payload for all endpoints. The following endpoints are affected:

• GET /object/{id}

• PUT /object/{id}

• POST /object/create

• GET /object/{id}/attributes

• POST /object/aql

• POST /object/navlist/aql

• GET /aql/objects

https://community.developer.atlassian.com/t/summable-attribute-removal-from-assets-rest-apis/85117

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 limit of 2 unique constraints per object type.

• Removing support for unique constraints on attributes with cardinality > 1

• Removing support for unique constraints on Text Area attributes

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 customers with any existing object types that breach these limits, we are asking these customers to please modify them before 31st of October 2024. Not doing this will delay our ability to migrate you to the new Assets platform.

Effected public Assets REST API endpoints are:

• POST /objecttypeattribute/{objectTypeId}

• PUT /objecttypeattribute/{objectTypeId}

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 or the attribute type is not supported.

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.

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.

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.

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.

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.

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.

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.

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.

It will no longer be possible to use AQL ORDER BY on an attribute of a linked object using dot notation. For example ORDER BY Laptop or ORDER BY Serial will continue to work as usual. However, ORDER BY Laptop.CPU will no longer be supported.

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.

See https://community.developer.atlassian.com/t/changes-to-assets-object-aql-and-object-navlist-aql-endpoints/79919 for details.

See https://community.developer.atlassian.com/t/object-attribute-value-id-will-be-removed-from-all-assets-rest-apis/79259 for details.

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