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 Cloud Platform.
For updates about changes to the Forge platform, see the Forge changelog in the Forge documentation.
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.
We are excited to announce that Connect apps can continue using dynamic webhooks after adopting Forge capabilities. Apps can manage webhooks using the REST API with JWT-based authentication. The guide to dynamic webhooks for Connect apps provides detailed instructions and information about existing restrictions to 100 webhooks and a 30-day expiration period.
This feature is enabled only for Connect apps adapting Forge capabilities. For Forge apps, we highly recommend relying on product events.
Developers need to ensure that their webhooks are registered correctly and refresh any expired webhooks.
We're introducing two new OAuth scopes, read:app-data:jira and write:app-data:jira for the following REST endpoints:
These new scopes are 100% optional now, and not using them won't break your app. However, we recommend adding them to your app's scope list at some point because we'll eventually make them mandatory.
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.
The Developer Assistant App, which manages the Developer Canary program, will require additional permissions to function, and therefore all users must approve an update manually.
Atlassian is changing the tools and processes we use internally to manage and roll out changes. We have released a new version of the Developer Assistant App to adapt to this. The old version of the app will stop working after Dec 1, 2024 . All instances currently enrolled in the Developer Canary program will stay enrolled, however you will need to install the new version of the Developer Assistant app to change your enrollment status.
This follows an RFC detailed in this Developer Community thread.
For more information about the Developer Canary program, or installing the Developer Assistant App, please see this page.
We are pleased to share that the customer experience for Connect data residency is now generally available. This is inclusive of the data residency UI in the admin hub, which offers admins a clear and easy way for admins to manage their data.
Learn more about data residency for Connect Apps.
As we share this announcement with customers, Atlassian has encouraged customers to explore data residency options for their apps. Please be aware that this may result in a slight uptick in customer support inquiries concerning data residency.
Data residency for Connect apps is just one more way to make meeting a key customer trust requirement easier than ever. It enables Atlassian organization administrators to specify where subsets of their product data at rest are hosted.
To take advantage of data residency for your Connect-hosted app, you’ll need to store any in-scope data (data that’s in-scope for data residency) in Connect. Then, update:
Your manifest so Atlassian is aware of your data residency offering
Your Privacy & Security tab so that customers know about your app’s support for data residency
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.
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.
In the Workflow Designer, Shared Transitions are represented as individual lines from a source status to any port on a destination status. To replicate support this in the workflow APIs, we'll be moving away from the use of the from and to properties of a status layout and will instead start using a list of transition links and a toStatusReference to represent transitions. This will allow us to represent shared transitions as having individual lines in the new workflow editor.
This change will impact the following APIs:
The changes will be initially opt-in while we deprecate the from and to references on transitions. After the Oct 14, 2024 the old fields will no longer be available.
The current structure of workflow transitions in the workflow APIs doesn't provide users with the flexibility to connect shared transitions to different points on a status. This was supported in the workflow designer and was recently added to the newer workflow editor. As such, this layout information was lost in workflows and customers could only connect these transitions to the same port on their statuses.
To illustrate, let's consider reusing a transition for two statuses to enable users to consistently close an issue. Previously, the transition could only be directed to a single port on the closed status as shown below:
With the new format, users can now link the shared transition to two distinct points within on the status from their source status. This functionality mirrors the previous workflow diagram and offers users increased flexibility in organizing their workflows in the new workflow editor.
Transitions on the following APIs will now use the links and toStatusReference properties instead of the previous from and to properties:
Below is an example of the old and new format of the transitions.
Old | New |
|---|---|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
{
"id": "91",
"type": "DIRECTED",
"from": [
{
"statusReference": "10048",
"port": 5
},
{
"statusReference": "10057",
"port": 5
}
],
"to": {
"statusReference": "6",
"port": 7
},
"name": "Close"
} | 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
{
"id": "91",
"type": "DIRECTED",
"toStatusReference": "6",
"links": [
{
"fromStatusReference": "10048",
"fromPort": 5,
"toPort": 3
},
{
"fromStatusReference": "10057",
"fromPort": 5,
"toPort": 7
}
],
"name": "Close"
} |
Jul 8, 2024: Updates to these APIs will be available
Jul 8, 2024 - Oct 14, 2024: Both formats are available during the transition
Oct 14, 2024: We’ll discontinue support for updates and read queries in the old format
Support for this is already available for customers in the new workflow editor and has always been present in the old workflow editor. We recommend adopting the new format as soon as possible to avoid losing customer layout information on writes.
From Jul 8, 2024:
Apps can opt in to start receiving the new format on read APIs by passing the useTransitionLinksFormat=true to the Bulk get workflows API.
Apps can start using the new format for transition links for all workflow write and validation APIs like Bulk update workflows or Validate create workflows. A bad request error will be returned if both types of transition formats are used in these APIs.
By Oct 14, 2024:
Starting from this date, we’ll exclusively accept the updated format for reading data and decline any requests that use the to and from format for transitions.
We’ll be introducing a change to the schema of Forge issue worklog product events (created / updated).
Specifically, the author and updateAuthor fields of Worklog will no longer be mandatory.
To give you ample time to adjust, we're providing a 6-month deprecation period for the schema.
Therefore, the change will take place on Jan 8, 2025.
The schema for the Worklog entity will change from:
1
2
3
4
5
6
7
8
9
10
11
interface Worklog {
id: string;
issueId: string;
author: User;
updateAuthor: User;
created: string;
updated: string;
started: string;
timeSpent: string;
timeSpentSeconds: number;
}to
1
2
3
4
5
6
7
8
9
10
11
interface Worklog {
id: string;
issueId: string;
author?: User;
updateAuthor?: User;
created: string;
updated: string;
started: string;
timeSpent: string;
timeSpentSeconds: number;
}making the author and updateAuthor fields optional.
Note that this means that the author and updateAuthor may be missing from the payload when a worklog is created or updated by an anonymous user.
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.
Jira administrators can now share dashboards to groups they are not part of when creating, sharing/renaming, or copying a dashboard.
You can now use:
extendAdminPermissions - a boolean which users with Administer Jira global permissions can set to true to share dashboards to groups they are not a member of.
CQL searches now support filtering by “smartlink” in addition to “embed“ to avoid confusion over the type for Smart Link in the content tree. Specifying “smartlink” as the type will retrieve the same results as when “embed“ equals type.
We’re happy to introduce a new batch of Jira Forge product events for the following entities:
Project (deleted)
Issue (deleted)
Attachment (deleted)
Comment (deleted)
Worklog (deleted)
Follow the links to read more about them.
Some time ago, we announced the introduction of a Jira admin webhooks limit, believing it to be a step in the right direction regarding the scalability and reliability of Jira webhooks.
However, after doing more in-depth research, we decided that we can't introduce this limit today. The customer impact would be too big, as we have identified third-party software integrating with Jira through admin webhooks.
Therefore, we're withdrawing the previous announcement and going back to the drawing board. We'll continue working until we find a solution that's satisfactory for everyone involved, especially our customers and partners.
We still strongly suggest that you keep the number of webhooks on your instance under 100, even if there’s no hard limit yet.
In the future, we'll announce any changes as far ahead of time as possible.
Currently, get issue API returns the first 20 worklogs by created date. After 19 December, 2024 the first 20 worklogs will be returned by start date.
This will also affect how worklogs are returned in search for issues using JQL GET and POST API.
If the change in the order of worklogs does not affect you, then you do not need to make any changes to your app.
For consumers who call get issue API to obtain the first 20 worklogs by created date, the get issue worklogs API will continue to return worklogs by created date.
If you need help with this change, ask in the Jira Cloud Development forum in the Developer Community.
Rate this page: