Rate this page:
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 Software 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.
We’re opening a 3 month deprecation period where Workflow status properties with the shape jira.permission[.subtasks].{permission}.group.[.suffix] will require a group id instead of a group name.
To ensure we can rename groups safely, we’ll no longer support group names in status properties.
If your workflow uses a status property with the shape jira.permission[.subtasks].{permission}.group.[.suffix], your admin will have to change the value to the group’s id.
Site admins can find a group’s id by going to Settings > User management > Groups. After selecting a group, the id will be at the end of the URL.
If your app uses the above Workflow status properties you will need to update your code to use group id’s instead of group name by the end of the deprecation period.
We previously announced the deprecation of JWT query strings as a means to authenticate to the product REST APIs as a Connect app in August 2021 - Action Required: Deprecating support for passing Connect JWTs as a query string parameter to Atlassian APIs. This was to be enforced on Feb 1, 2022, however the enforcement of this change was not comprehensive and a small number of apps continued to use the existing query string method.
We’re now proceeding with the complete removal of ?jwt= query string support from the Jira and Confluence APIs. If you currently still utilise JWT query strings, you will be allowlisted to continue until Aug 31, 2023 without any action on your end. After this date, the Atlassian Jira and Confluence APIs will no longer inspect the ?jwt= query string parameter and requests for all apps, and consequently may fail with a HTTP 401 response.
Please utilise the JWT auth header as a means to authenticate as outlined in: https://developer.atlassian.com/cloud/jira/platform/understanding-jwt-for-connect-apps/#creating-a-jwt-token
Accepting sensitive JWTs as a query string parameter presents a problem as the query string is often saved in web browser history, passed through Referers to other web sites, stored in web logs such as intermediate proxy servers.
If your app provides its Connect JWT to the Atlassian APIs as a query string parameter, you must update it to pass the JWT via an Authorization: JWT header.
We’re now proceeding with the complete removal of ?jwt= query string support from the Jira and Confluence APIs. If you currently still utilise JWT query strings, you will be allowlisted to continue until Aug 31, 2023 without any action on your end. After this date, the Atlassian Jira and Confluence APIs will no longer inspect the ?jwt= query string parameter and requests for all apps, and consequently may fail with a HTTP 401 response."
Added Singapore as supported realm for Connect data residency.
As a reminder, if you indicate support for a realm, it means your app stores the relevant, in-scope data only in that realm - any in-scope data that your app stores must be stored in that realm. You should not declare the regionBaseURL for Singapore unless you use storage infrastructure in Singapore to pin in-scope data for customers in this region. For more information, please refer to the Connect data residency documentation.
The team custom field type key com.atlassian.teams:rm-teams-custom-field-team will be removed in favor of the new team custom field type key com.atlassian.jira.plugin.system.customfieldtypes:atlassian-team
As part of changes coming to Teams, the Team custom field type will change from com.atlassian.teams:rm-teams-custom-field-team to com.atlassian.jira.plugin.system.customfieldtypes:atlassian-team
Currently, the Team custom field type is only available for use in Jira Software Premium.
The output of the Get fields REST API will change slightly in the field type schema response.
Before
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
{
"id": "customfield_10001",
"key": "customfield_10001",
"name": "Team",
"untranslatedName": "Team",
"custom": true,
"orderable": true,
"navigable": true,
"searchable": true,
"clauseNames":
[
"cf[10001]",
"Team",
"Team[Team]"
],
"schema":
{
"type": "any",
"custom": "com.atlassian.teams:rm-teams-custom-field-team",
"customId": 10001,
"configuration":
{
"com.atlassian.jira.plugin.system.customfieldtypes:atlassian-team": false
}
}
}
After
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
{
"id": "customfield_10001",
"key": "customfield_10001",
"name": "Team",
"untranslatedName": "Team",
"custom": true,
"orderable": true,
"navigable": true,
"searchable": true,
"clauseNames":
[
"cf[10001]",
"Team",
"Team[Team]"
],
"schema":
{
"type": "team",
"custom": "com.atlassian.jira.plugin.system.customfieldtypes:atlassian-team",
"customId": 10001,
"configuration":
{
"com.atlassian.jira.plugin.system.customfieldtypes:atlassian-team": true
}
}
}
The shape of the field data on the issue will remain backwards compatible.
3 months from this notice we will rollout a change that will affect the value returned in the schema.custom property from the Get fields REST API, specifically for the Team custom field (available in Jira Software Premium Edition). The value will change
from com.atlassian.teams:rm-teams-custom-field-team
to com.atlassian.jira.plugin.system.customfieldtypes:atlassian-team
If your app relies on this property value schema.custom=com.atlassian.teams:rm-teams-custom-field-team to identify the Team custom field
Add forward compatible support for the new property value
Ensure the app supports the case where the old property value is no longer present
This can be safely done by supporting both property values for the Team custom field type.
Note: The new key will be available for reference during the deprecation period in schema.custom.configuration
1
2
3
4
5
6
7
8
9
10
11
12
13
14
{
"id": "customfield_10001",
"name": "Team",
"schema":
{
"type": "any",
"custom": "com.atlassian.teams:rm-teams-custom-field-team",
"customId": 10001,
"configuration":
{
"com.atlassian.jira.plugin.system.customfieldtypes:atlassian-team": false
}
}
}To help you debug your Forge apps, the developer console now lets you group your metrics by app function. Each chart now has a Group by dropdown menu, with the option to select Function. For more information, see Monitor your apps.
We’ve introduced a new metric to the developer console - invocation time! You can now see the invocation time for your Forge apps by selecting Metrics in the left menu and scrolling to the new invocation time chart, which shows the speed of your function invocations, separated into time buckets.
You can also select the Go to detailed view link at the bottom of the chart, to get a more in-depth view of invocation time, including the P50, P90, and P95 for individual functions.
We're happy to announce that the custom field and custom field type modules are leaving the Early access program and are becoming generally available. Both modules are ready for production use and we're committed to maintaining them in the current state. We also won’t release any changes that would break backward compatibility without at least six months' notice.
The value of the hierarchyLevel property of issuetype will be its level in Hierarchy Configuration. For example, an issue type at level 2 in the issue type hierarchy will now have a hierarchyLevel of 2.
This change will be released after Apr 1, 2023. It will affect all API endpoints that return issuetype as part of the issue fields.
Previously, hierarchyLevel was 0 for issue types at levels ≥ 1 in Hierarchy Configuration. Only the system Epic issue type had hierarchyLevel 1.
There will be no change in hierarchyLevel for base-level issue types (0) and subtasks (-1).
It’s now easier to avoid exceeding your API call rate limits. We’re adding a new response header to Jira - X-RateLimit-NearLimit. On a successful call, receiving this header with a true value means that you have less than 20% of your cost-based rate limiting budget left.
For more information on this subject, see https://developer.atlassian.com/cloud/jira/platform/rate-limiting/.
To make it easier and safer to distribute your Forge app via the developer console, you can now generate new installation links. When you generate a new link, users with the previous link will no longer be able to install your app (however, they can still update to new versions). This gives you more control when distributing your app to specific audiences.
On January 18, 2023, we'll be extending the length of API tokens for Atlassian accounts, API keys, and Repository Access Tokens. This ensures new tokens and keys generated after this date are more secure and reliable. Tokens and keys created before January 18, 2023 won’t be affected.
In the developer console, you can now edit the target value of your Forge app alert. Previously, the alert was set at a target value of 99%. Now you can choose from a number of values between 99% and 60%.
For more information, see Manage app alerts.
Plan-only teams (also known as private teams) will no longer be usable outside of an Advanced Roadmaps plan, specifically in the Team field via Jira REST APIs and JQL queries.
These changes do not affect the use of shared teams.
Plan-only teams (also known as private teams) will no longer be usable outside of an Advanced Roadmaps plan, specifically in the Team field via Jira REST APIs and JQL queries. This does not affect the use of shared teams.
Plan-only teams are not provided as JQL Suggestions for the Team field, however it is possible to query a plan-only team directly by it’s id. After this change, querying plan-only teams directly by id will no longer return any results.
Plan-only teams will also no longer be exposed in the Team field of an issue on the Jira Get Issue REST API, nor be settable via the Create or Edit Issue REST API. Previously only the id and a place-holder title “Plan-specific team" were returned. After this change, the field will appear empty.
This change also affects the REST API and Jira Smart values; after this change takes effect, the following attributes of the exposed custom field data will be deprecated:
The “title” attribute will be deprecated in favour of the “name” attribute
The “isShared” attribute will be deprecated and can assumed to be true as only shareable teams will be returned by the API.
All functionality for shared teams will continue to be supported.
If you have plan-only teams you wish to use outside of the plan, you may convert these to share teams to continue to be able to use them
If you use the "title" attribute, of the team custom field, replace this use with the "name" attribute
If you use the "isShared" attribute, of the team custom field, it will no longer be required - replace this with the assumption the value is always true
For example, in the Jira Rest API:
GET /rest/api/{version}/issue/{issueIdOrKey}
1
2
3
4
5
6
"customfield_10001":{
"id":"6",
"name":"My team",
"title":"My team", -- deprecated, use "name"
"isShared":true -- deprecated, assume true
}
For example, in Jira Smart values
replace
1
{{issue.Team.title}}with
1
{{issue.Team.name}}The change will be progressively rolled out 3 months from this notice.
The full-page issue create experience will be retired for all Jira Cloud customers over the next 6 months. Although there is no formal API for the full-page issue create experience, it’s possible that some apps may be relying on it and will need to be updated. For more information, read this community post.