This page includes release notes and updates for Jira Cloud app developers. Use this page to keep track of upcoming changes, deprecation notices, new features, and feature updates from Jira Service Management Cloud.
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 users of the Jira Cloud products are announced.
The upper limit of for Data security policy events has been increased to 200,000 objects, from the previous limit of 50,000 objects.
How does the upper limit work
This means that if a customer activates or updates a data security policy that affects more than 200,000 objects, you will receive the first 200k objects in the events and the rest would be omitted.
Data security policies help customers keep their organization’s data secure by letting them govern how users, apps, and people outside of their organization can interact with content such as Confluence pages and Jira issues.
Data security policy events are generated when installed apps' access to certain data within Confluence, Jira, Jira Service Management, or Jira Software has been blocked by an administrative policy with an App access rule. App developers can subscribe to these events, we encourage you to read the Developer guide.
As we deprecate less secure and older cipher suites, some customers using Basic Authentication may experience connectivity issues between Jira and connected email accounts due to the “Remote host terminated the handshake” error. As a result, your service project may not receive requests and comments from incoming emails to Jira. This change will take effect on August 5, 2024.
To avoid disrupting these incoming emails, you must review your existing email server configurations and ensure they use one of the supported TLS cipher suites. The process may vary based on the email server software you’re using.
"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.
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.
Connect apps adopting Forge can now register, retrieve and delete new and existing dynamic modules.
For more information, refer to Incrementally adopting Forge from Connect.
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.
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.
Connect apps registered on Forge are no longer able to set `app.connect.authentication: oauth2` in their manifest. This caused client credentials to be sent in the installation hook that could be exchanged for an api.atlassian.com access token. Developers wishing to make requests to api.atlassian.com from their app server should use Forge Remote instead. If you were relying on this feature, we’re happy to answer questions you may have about migrating on the Developer Community forums.
Forge functions can now interact with remote backends utilising Forge Remote. This capability makes it simpler and more secure to integrate remote backends with your Forge app.
See Forge Remote - Calling a remote backend from a Forge function for more information.
Assets now supports JWT authentication. See https://developer.atlassian.com/cloud/assets/imports-rest-api-guide/authorization/#connect-apps for more details.
The “create_request” value has been removed from the list of allowed values for the page property of the Customer portal module, as it is no longer applicable with the merger of portal and create request pages in Customer Portal.
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.
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.
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 asobject 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.
A new RFC is ready for review at https://community.developer.atlassian.com/t/rfc-51-multiple-help-centers-on-jira-service-management/79958.
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.
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.
We have now fixed the incorrect scope check requests with a trailing forward slash.
Assume there is a scenario where a request is made to an endpoint https://api.atlassian.com/some/path/. Scope checking may find a valid scope for path /some/path/** and pass the scope check. Once the request reaches the backend service, if the service does not have a path with a trailing slash, it may remove it and invoke the parent endpoint https://api.atlassian.com/some/path which may not have the same scope requirements.
With this fix, scope checking will ignore the trailing slash when matching scopes to the path.
This means that a request to https://api.atlassian.com/some/path/ and https://api.atlassian.com/some/path will be treated the same with respect to scope checking.
The progressive rollout of data security policy events has been completed. Data security policy events are generated when installed apps' access to certain data within Confluence, Jira, Jira Service Management, or Jira Software has been blocked by an administrative policy with an App access rule. You can now subscribe to these events.
Being a new capability however, we are scaling up our processing of these data security policy events over the next few months. In the meantime we have set a upper limit of 50,000 objects. This means that if a customer activates or updates a data security policy that affects more than 50,000 objects, you will receive the first 50k objects in the events and the rest would be omitted.
We intend to raise these limits and will advise once we have reached our final threshold— and have determined our final hard limits.
Data security policies help customers keep their organization’s data secure by letting them govern how users, apps, and people outside of their organization can interact with content such as Confluence pages and Jira issues.
The new app access rule under data security policies allows customers to restrict app access to the content in Confluence spaces or Jira projects under a given policy. In this way, customers can benefit from apps while still limiting 3rd-party app access to certain content in select spaces.
If you are looking to update your apps with custom in-app messaging whenever your app is affected by an app access rule, we encourage you to use the Developer guide.
Rate this page: