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’re happy to introduce a new Jira Forge product event:
Project version deleted - avi:jira:deleted:version
Follow the link above to read the event’s documentation.
UI modifications, the Forge module that allows apps to modify fields, now supports the original estimate field on the Issue view.
For more information, see the list of supported fields for Issue view.
We’ve stopped injecting stylesheets for Connect apps via inline styles, in favour of loading from the Connect CDN. This affects the Theming API and dynamic content macros that supported the legacy Confluence editor.
We originally announced this 6 months ago, in line with our standard deprecation policy. It is now live for https://developer.atlassian.com/cloud/confluence/developer-canary-program tenants, and will roll out to all customers widely throughout this week.
If your app doesn’t use the above Connect features, or doesn’t use a Content Security Policy (CSP) for style-src, no action is required. Otherwise, please read the details here or see https://developer.atlassian.com/platform/marketplace/security-requirements/#connect-apps on how to modify your CSP to support these changes.
To support these changes in your app, if you're using a Content Security Policy that sets the style-src policy, you must add the Connect CDN (https://connect-cdn.atl-paas.net) to your policy to allow these stylesheets to be injected. It's safe to remove unsafe-inline from your policy if you've been using it up until now.
The stylesheets mentioned here were included automatically via the Connect JS script, not manually by the app vendor. There are two circumstances under which Connect injected stylesheets into your app:
The first is only for apps which opted in to the Theming API.
The theme stylesheets previously loaded via an inline stylesheet, which forced vendors to adopt the insecure unsafe-inline policy, and is the main motivation for this change.
The second location is only for dynamic content macros.
We injected a stylesheet with CSS classes representing colors from the legacy Confluence editor.
This happened without opt-in, to be backwards-compatible with macros created in the legacy editor.
This injection was done via CSSOM, not inline styles, and therefore isn’t impacted by style-src CSP rules currently. However, it is also now being served from the CDN.
To summarise, all styles are now being loaded from the CDN, and the inline/CSSOM methods have been removed.
The navigation changes to Jira, JSM, JPD, and Atlassian Home have now moved from EAP to Beta. For partners, this is an extension of the previously announced EAP. This extended EAP will enable partners to test the new navigation and assess how apps will adapt to the proposed changes. Unlike the previous EAP, the design direction is now near final, so we recommend partners start adopting the new navigation.
As part of the extended EAP, we’ve set up a dedicated group on CDAC where you can discuss these changes. To join the beta launch, register through the EAP form.
Please visit the community post https://community.atlassian.com/t5/Navigation-Refresh-articles/What-s-changing-in-Apps-with-Atlassian-s-Beta-launch-of-New/ba-p/2871925 where you will find detailed information about the changes, recommendations, and a comprehensive FAQ section tailored for our partners.
Progressive Rollout: This change will be applied to all sites over the coming weeks.
Following the previous deprecation notice, changelogs for Epic Link and Parent Link field values are no longer available from Jira Cloud REST API. We recommend using the IssueParentAssociation changelog items instead.
For webhooks in Jira, we recommend consuming the IssueParentAssociation items, as mentioned in this community announcement (see Change 6).
Jira Forge now supports string, object, and number custom fields on the new Transition view. Note that you have to enable the view on your instance to be able to use it.
For more information about the Transition view, go to our documentation.
We are removing mirrors of third-party packages such as maven-central from packages.atlassian.com
We're updating how we provide packages for customers and partners to develop with our platforms. Starting February 1, 2025, we will discontinue providing third-party packages on packages.atlassian.com. Instead, customers and partners must fetch these packages directly from the original upstream repositories.
For details on how this change affects you and for guidance on migration, please refer to the documentation available at http://developer.atlassian.com .
We are extending the forms available in Jira business projects today, to Jira software projects. This will give customers a new way to intake work from stakeholders. Only Jira and project admins (or users with project admin permissions) will be able to create, edit, and delete forms. Forms will be available for all licence editions and will be accessible from a projects navigation. They can also be toggled on/off in project settings. Forms are scoped to a single project and issue type within that project.
In addition to this project, we will be adding a number of other enhancements to forms in the coming months.
These include:
L1+ (epic level and above) issue type support
Required fields
Field descriptions
Conditional logic
There are no specific APIs or UI extension points currently available in Connect or Forge for forms today.
You can now migrate existing Connect dashboard items to the Forge dashboard gadget module.
This change allows your app to render existing Connect dashboard items as Forge dashboard gadgets when you adopt a Forge gadget with a key matching the Connect dashboard item.
See Migrate Jira modules from Connect to Forge for more information, including how to preserve the Connect dashboard item’s data when migrating it to a Forge module.
What is changing?
We’re deprecating the following Jira Platform REST endpoints:
GET /rest/api/3/search - Search for issues using JQL (GET)
POST /rest/api/3/search - Search for issues using JQL (POST)
POST /rest/api/3/search/id - Search issue IDs using JQL
POST /rest/api/3/expression/eval - Evaluate Jira expression
There is a deprecation period of 6 months, and these endpoints will be removed after May 1, 2025.
Why are we making this change?
Over the years, Jira has grown its customer base, and people are using Jira on a larger scale and in more complex ways. JQL is one of the core capabilities of Jira, and we’ve noticed that the JQL APIs, which used to work very well, are now being challenged by the scale and complexity of how people are using the APIs. JQL needs to evolve to remain reliable, performant, and scalable to serve bigger, more complex use cases.
The mentioned endpoints expose parameters that aren't compatible with the new JQL service. Therefore, we’re replacing them with compatible ones.
For a list of replacement endpoints, and other information, see More details below.
What are the replacement endpoints?
Here is a list of recommended replacements.
Deprecated Endpoint | New Endpoint |
|---|---|
| No direct replacement, similar behaviour can be achieved with |
|
What are the differences between the old and new endpoints?
We have tried to make the new endpoints as compatible as possible with the previous ones, however there are some breaking changes:
By default, the endpoint will only return Issue IDs. Unless requested, all other issue fields will be omitted in the Issue objects. You can request them by using the fields property.
The endpoint doesn’t provide immediate search after write consistency. Search results may not incorporate recent changes made by users. If this behaviour is important for your case, please refer to the migration path at the end of this page. The delay for updates to be visible in search is dependent on various factors. The majority of modifications are typically visible within seconds. However, operations that impact numerous issues, such as lexorank rebalancing or bulk editing, may require more time to complete.
The validationMode parameter is removed and validation will work as none.
We’ll replace random page access with a continuation token API. This means you won’t be able to get multiple pages at the same time with parallel threads. startAt parameter will be replaced with nextPageToken.
We will only return a maximum of 20 comments and 40 changelog items. If you require more, please refer to the migration guide at the end of this page.
The endpoint won’t accept unbounded JQL query and will return 400 if an unbounded JQL query is provided.
More details available here → https://support.atlassian.com/jira-software-cloud/docs/what-is-advanced-search-in-jira-cloud/#Types-of-JQL
Additionally, we’re introducing two new endpoints to complete the solution:
This operation may be achieved by using two Jira endpoints:
Get issue IDs via /rest/api/3/search/jql
1
2
3
4
5
6
curl --location 'https://example-jira.atlassian.net/rest/api/latest/search/jql' \
--header 'Content-Type: application/json' \
--header 'Accept: application/json' \
--data '{
"jql":"project in (FOO, BAR)"
}'Response:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
{
"issues": [
{
"id": "10068"
},
{
"id": "10067"
},
{
"id": "10066"
}
],
"nextPageToken": "CAEaAggD"
}Get issues’ fields with Bulk Fetch API to /rest/api/{2|3|latest}/issue/bulkfetch
1
2
3
4
5
6
7
8
curl --location 'https://example-jira.atlassian.net/rest/api/latest/issue/bulkfetch' \
--header 'Content-Type: application/json' \
--header 'Accept: application/json' \
--data '{
"issueIdsOrKeys": ["FOO-1","10067", "BAR-1"],
"fields": ["priority", "status", "summary"]
}'You can use the Bulk Fetch Issue endpoint:
POST to /rest/api/{2|3|latest}/issue/bulkfetch
Example request:
1
2
3
4
5
6
7
curl --location 'https://example-jira.atlassian.net/rest/api/latest/issue/bulkfetch' \
--header 'Content-Type: application/json' \
--header 'Accept: application/json' \
--data '{
"issueIdsOrKeys": ["FOO-1","10067", "BAR-1"],
"fields": ["priority", "status", "summary"]
}'You can use approximate count endpoint:
POST /rest/api/3/search/approximate-count
1
2
3
4
5
6
curl --location 'https://example-jira.atlassian.net/rest/api/latest/search/approximate-count' \
--header 'Content-Type: application/json' \
--header 'Accept: application/json' \
--data '{
"jql":"project in (FOO, BAR)"
}'Response
1
2
3
{
"count": 3
}You can use the JQL Parse endpoint:
POST /rest/api/3/jql/parse
1
2
3
4
5
6
curl --location 'https://example-jira.atlassian.net/rest/api/latest/jql/parse' \
--header 'Content-Type: application/json' \
--header 'Accept: application/json' \
--data '{
"queries":["project in (FOO, BAR)"]
}'Response
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
{
"queries": [
{
"query": "project in (FOO, BAR)",
"structure": {
"where": {
"field": {
"name": "project",
"encodedName": "project"
},
"operator": "in",
"operand": {
"values": [
{
"value": "FOO",
"encodedValue": "FOO"
},
{
"value": "BAR",
"encodedValue": "BAR"
}
],
"encodedOperand": "(FOO, BAR)"
}
}
}
}
]
}We recommend following Search And Reconcile pattern described here.
POST /rest/api/3/search/jql
Use next page token returned on each request to get further results
1
2
3
4
5
6
7
curl --location 'https://example-jira.atlassian.net/rest/api/latest/search/jql' \
--header 'Content-Type: application/json' \
--header 'Accept: application/json' \
--data '{
"jql":"project in (FOO, BAR)",
"maxResults": 1
}'Response:
1
2
3
4
5
6
7
8
9
10
11
{
"issues": [
{
"expand": "operations,versionedRepresentations,editmeta,changelog,renderedFields",
"id": "10068",
"self": "https://example-jira.atlassian.net/rest/api/latest/issue/10068",
"key": "FOO-1"
}
],
"nextPageToken": "CAEaAggB"
}Request
1
2
3
4
5
6
7
8
curl --location 'https://example-jira.atlassian.net/rest/api/latest/search/jql' \
--header 'Content-Type: application/json' \
--header 'Accept: application/json' \
--data '{
"jql":"project in (FOO, BAR)",
"maxResults": 1,
"nextPageToken": "CAEaAggB"
}'Response
1
2
3
4
5
6
7
8
9
10
11
{
"issues": [
{
"expand": "operations,versionedRepresentations,editmeta,changelog,renderedFields",
"id": "10067",
"self": "https://example-jira.atlassian.net/rest/api/latest/issue/10067",
"key": "BAR-2"
}
],
"nextPageToken": "CAEaAggC"
}GET /rest/api/3/issue/{issueIdOrKey}/comment
1
2
3
4
curl --location 'https://example-jira.atlassian.net/rest/api/latest/issue/BAR-1/comment' \
--header 'Content-Type: application/json' \
--header 'Accept: application/json' \
--data ''Response
1
2
3
4
5
6
7
8
{
"startAt": 0,
"maxResults": 100,
"total": 3,
"comments": [
...
]
}Use Get changelogs endpoint
GET /rest/api/3/issue/{issueIdOrKey}/changelog
1
2
3
curl --location 'https://example-jira.atlassian.net/rest/api/latest/issue/BAR-1/changelog' \
--header 'Content-Type: application/json' \
--header 'Accept: application/json' \`Response:
1
2
3
4
5
6
7
8
9
10
{
"self": "https://example-jira.atlassian.net/rest/api/2/issue/BAR-1/changelog?maxResults=100&startAt=0",
"maxResults": 100,
"startAt": 0,
"total": 3,
"isLast": true,
"values": [
...
]
}You can use the new evaluate expression endpoint POST /rest/api/3/expression/evaluate
Example request for the first page
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
curl --request POST \
--url 'https://example-jira.atlassian.net/rest/api/3/expression/evaluate' \
--header 'Content-Type: application/json' \
--header 'Accept: application/json' \
--data '{
"context": {
"issues": {
"jql": {
"maxResults": 5,
"query": "summary ~ \"task\"",
}
}
},
"expression": "issues.map(i => i.summary)"
}'Response:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
{
"value": [
"task 7",
"task 6",
"task 5",
"task 4",
"task 3"
],
"meta": {
"issues": {
"jql": {
"nextPageToken": "CAEaAggF"
}
}
}
}Example request for subsequent pages
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
curl --request POST \
--url 'https://example-jira.atlassian.net/rest/api/3/expression/evaluate' \
--header 'Content-Type: application/json' \
--header 'Accept: application/json' \
--data '{
"context": {
"issues": {
"jql": {
"maxResults": 5,
"query": "summary ~ \"task\"",
"nextPageToken":"CAEaAggF"
}
}
},
"expression": "issues.map(i => i.summary)"
}'Response:
1
2
3
4
5
6
7
8
9
10
11
12
{
"value": [
"task 2",
"task 1",
"test task"
],
"meta": {
"issues": {
"jql": {}
}
}
}We don't recommend running unbounded JQL queries – they are slow for users and costly for every system involved. As our customers grow in number and size over time, with millions of Jira issues, this trend will continue.
We strongly recommend you bound your JQL queries to give customers the best performance and reliability. Consider bounding your queries like this:
1
updated > -1mMore information is available here
The eventual consistency delay is dependent on various factors. 99% of modifications are typically visible within seconds. However, non organic updates or operations that impact numerous issues, such as lexorank rebalancing or bulk editing, may require more time to complete.
Depending on your needs, we recommend the following:
Polling with overlapping periods of 5 minutes if you do not rely on non-organic updates.
Polling with overlapping periods of 25 minutes if you do depend on non-organic updates, or if you are depending on results of operations that impact numerous issues.
To increase the level of assurance, we recommend combining the above tactics with the consumption of Webhook events.
UI modifications, the Forge module that allows apps to modify fields, now supports the original estimate field on the Issue transition view.
For more information, see the list of supported fields for Issue transition.
Our products have been in the process of transitioning to the Grouped View for rendering notifications instead of the previously used List View.
The notification logic for the view type is internal and there are no existing APIs available to app developers to control or interact with that. Therefore no actions are needed and apps don’t require any update as we complete the roll-out of the Grouped View and phase out the List View one.
EDIT, 24 Oct 2024: Clarified that there is no impact on apps due to this change and changed the changelog type to Announcement.
The fields baseline_start (also known as Target start) and baseline_end (also known as Target end) will no longer be available via the Issue properties API.
Moving forward, the Edit Issue API will be the only supported method for updating these properties.
Note: You can still access the existing values using the Issue properties API. However, any updates to these values will not appear in the UI, and they may not reflect the most current information.
This change will take effect on or after November 22, 2024.
To adapt to this change, please start using the Edit Issue REST API for updating the baseline_start and baseline_end fields.
If you're unsure how to implement these updates, here's a quick guide:
Use the Get Edit Issue Metadata API to get the list of the fields
From the response, get the custom field ids where the schema.custom is com.atlassian.jpo:jpo-custom-field-baseline-start or com.atlassian.jpo:jpo-custom-field-baseline-end
Once you have your custom field IDs, use the Edit Issue REST API to update the fields.
The Atlassian Connect in Jira Cloud project in the Atlassian Ecosystem Jira tracks issues with Atlassian Connect in Jira and its REST API. To improve response times, we’re no longer accepting new issues in this Jira project as of this announcement. Instead, we encourage our partners to file issues with Developer and Marketplace support.
The Atlassian Connect Spring Boot and Atlassian Connect Express (Node.js) projects in the Atlassian Ecosystem Jira track issues with the two frameworks. To improve response times, we’re no longer accepting new issues in these Jira projects as of this announcement. Instead, we encourage our partners to file issues with Developer and Marketplace support.
Rate this page: