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 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’ve added a new screen tabs API to Jira Cloud Platform. The get bulk screen tabs API allows you to get tabs from multiple screens, filtered by tab ID and/or screen ID. Follow the link for detailed documentation.
To improve the performance of workflow updates, we’re no longer recording them on an issue’s history. APIs like Get changelogs won’t display workflow updates anymore.
Two fields that were previously only available through an API call are now available through the /installed lifecycle event. From today the /installed lifecycle event will return with 2 additional fields: entitlementId and entitlementNumber where available. For documentation on this event, see this page.
When consumers trying to add custom fields with invalid scope to a global screen tab, API returns 500 internal server error instead of a 400 Bad Request.
This change is for the API return 400 bad request instead of 500 when a custom field with Project scope is passed as parameter.
Current
Error code: 500
Error message: "Internal server error"
New:
Error code: 400
Error message: "<<field_id>> is a team-managed field and you can't add it to a global screen."
Progressive rollout by region/tenant pending
As of 8th of September 2023, we’re removing the ability to use group names shaped like jira.permission[.subtasks].{permission}.group.[.suffix]in workflow status properties. Entities that haven’t been translated from group name to group ID will no longer work as expected.
To ensure we can rename groups safely, we 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’ll need to update your code to use group IDs instead of group names by the end of the deprecation period on 8th of September 2023.
In October 2023, Atlassian plans to add support for Canada to Connect apps, alongside existing data residency regions available to customers. Once this region is available, we will be updating our data residency supported region keys to include Canada (CA) alongside our existing supported data residency regions. We will provide further updates closer to availability.
As a reminder, if you indicate support for a realm, it means your app stores the relevant data that is in-scope for your app’s data residency solution (see Atlassian’s documentation on in-scope data for our products here). For more information, please refer to the Connect data residency documentation.
In addition to Canada, Atlassian is exploring making additional data residency regions available in the future. These can be identified on the Atlassian Cloud Roadmap and we will provide similar updates/notice prior to these regions being available.
UI modifications, the Forge module that enables apps to modify fields, now allows you to create UIMs on the Global issue create modal for Jira Work Management projects.
For more information, see the list of supported project types for GIC.
We’re pleased to announce a preview release of support for a new location via the UI modifications extension point: Issue view.
It’s the second Jira location to be supported, following the initial support for the Global issue create modal.
Documentation specific to the Issue view is available under this link. The supported fields and methods are listed here.
To assign a UI modification to the Issue view context, you need to pass a viewType equal to IssueView while creating or updating the UI modification. See more details in our REST API docs.
At the same time, we’re ending the UI modifications Issue View Early Access Program. Your apps developed during the EAP will continue to work.
Jira Cloud Platform features new workflow scheme APIs for company-managed and team-managed projects, allowing you to programmatically retrieve and update the details of workflow schemes. These new APIs are all declarative, allowing you to define the desired end state as well as system transitions from your current state to the desired state.
The new APIs are:
Bulk get workflow schemes: return a list of workflow schemes.
Update workflow schemes: update a workflow scheme.
Get required status mappings for workflow scheme update: get the required status mappings for the desired changes to a workflow scheme.
Support for atlassian-connect-spring-boot 3.x will end on 18 November 2023.
Apps must migrate to atlassian-connect-spring-boot 4.x during this period.
We have released a Spring Boot 3.x compatible version for Atlassian Connect Spring Boot (ACSB 4.x). To continue to be supported, please upgrade by November 18 2023.
With this release, you can start to migrate apps to ACSB 4 and Spring Boot 3.
This release includes these updates:
Migration to Spring Boot 3.1.0.
Migration to Java 17.
The previous 2.7.x version of Spring Boot is reaching End Of Life (EOL) by November 18th 2023 (Spring Boot).
In 6 months, we will enforce limits per issue for the number of:
Comments: 5000 comments per issue
Worklogs: 5000 worklogs per issue
Attachments: 2000 attachments per issue
Issue links: 2000 issue links per issue (excluding child issues and subtasks)
Remote links: 2000 remote issue links per issue
An error response will occur if the limit is exceeded for:
Operations via REST APIs
Automation rules
Issue transitions
If issue data already exceeds the limits, this will be transformed into an attachment within the issue.
Limits on the number of list field Items allowed per issue
Maximum limits per issue | Impacted APIs | Operations will result in an error after the change | Old response | New response |
|---|---|---|---|---|
5000 comments per issue |
|
|
|
message: |
5000 worklogs per issue |
|
|
|
message: |
2000 attachments per issue |
|
|
|
message: |
2000 issue links per issue (excluding child issues and subtasks) |
|
|
|
message: |
2000 remote links per issue |
|
|
|
message: |
The above limits per issue will also apply to site import and JCMA migrations. Instead of an error, issues with field data over the limit will have a transformation rule applied, such that the field data over the limit is converted into attachments on the issue.
Existing issues with field data over the limit will have a transformation rule applied, such that the field data over the limit is converted into attachments on the issue.
Whilst the vast majority of our issues are associated with a reasonable amount of comments, worklogs, attachments, issue links and remote links, there are some issues with extreme data shapes on an issue. These large data sizes can lead to reliability issues and incidents in unpredictable ways.
No changes to your app, automation or workflows are necessary if
you aren’t working with the APIs listed above
you know none of your issues would have fields that are over the limit
If your app/automation/workflows are performing operations that would cause it to exceed limits, you need to handle the new error message appropriately.
If your app/automation/workflows needs to create comments/worklogs/attachments/issue links/remote links in an issue that will cause the limit to be exceeded, consider creating them in another issue.
If your app/automation/workflows needs to update comments/worklogs/attachments/issue links/remote links in an issue that is already exceeding limit for that field, consider moving items to another issue before attempting the update.
Th deprecation period is 6 months.
As per Understanding JWT for Connect apps and our previous deprecation notice, the Jira and Confluence APIs now only allow Connect apps to provide authentication JWTs as an Authorization: JWT header in requests. 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
This change does not affect how Jira or Confluence provides the Atlassian product JWTs to Connect app modules/iframes.
Please note: This removal will progressive rollout by tenants, increasing to 100% by the 15th September, 2023
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.
The Connect lifecycle HTTP request payload for both Jira and Jira Service Management (JSM) now contains two new fields for apps installed on sites participating in the custom domains beta. These reflect any custom domains configured for each product:
displayUrl: The custom domain for Jira;
displayUrlServicedeskHelpCenter: The custom domain for JSM.
The updated payload:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
{
"key": "my-app",
"clientKey": "redacted",
"publicKey": "redacted",
"sharedSecret": "redacted",
"serverVersion": "100234",
"pluginsVersion": "1001.0.0-SNAPSHOT",
"baseUrl": "https://my-service-desk.jira-dev.com",
"displayUrl": "https://stg-test-22aug-1239.jira.staypositive.au",
"productType": "jira",
"description": "Atlassian JIRA at https://my-service-desk.jira-dev.com",
"eventType": "installed",
"cloudId": "f3fa27a2-189a-4ea5-a06c-374567baf7d5",
"displayUrlServicedeskHelpCenter": "https://stg-test-22aug-1352.jsm.staypositive.au"
}If no custom domains have been added to the Jira or JSM, then the value of these fields will fallback to baseUrl, which is the default site URL.
Please note that API requests from your App should always use the baseUrl. The displayUrl and displayUrlServicedeskHelpCenter properties should only be used when displaying or rendering URLs.
UI modifications, the Forge module that allows apps to modify fields, now supports the issue type system field for Global issue create modal.
For more information, see the list of supported fields.