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.
The issue context Forge module now allows you to use dynamic properties to set a dynamic status value.
This feature was previously available for issue glances, which will get deprecated on Oct 6, 2023.
The route template function (used to access Atlassian product APIs) now blocks more potentially malicious user input; this helps prevent vulnerabilities like path traversal in Forge apps. We’ve implemented this enhanced security through additional checks that only apply to the path segment of the URLs being constructed (not query strings).
If you are sure the input is legitimate and cannot lead to an unexpected API call, you can encode it manually or use assumeTrustedRoute.
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.
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.
It’s now possible to filter Jira webhooks by Connect app license status using conditions in the webhook module.
Add the addon_is_licensed condition to the webhook module in your Connect descriptor to filter out webhooks from apps without a license.
Example:
1
2
3
4
5
6
7
8
9
{
"event": "jira:issue_created",
"url": "/atlassian/jira/issue_created",
"conditions": [
{
"condition": "addon_is_licensed"
}
]
} We have begun using 4 new security scanners for Connect security requirements on the Atlassian Marketplace. The new scanners will be used to check your Connect apps for:
Signed Install Authentication (Req 1.4)
Authorization (Req 1.2)
Input Validation (Cross-Site Scripting) (Req 8)
Insecure Storage of Secrets (Req 5)
See our announcement for new scans enabled on Connect apps: https://atlassianpartners.atlassian.net/l/cp/Xki0k1Pp
As always, we will notify you of any apps that are found to be missing security requirements via the Atlassian Marketplace Security Jira Project. As a reminder, all apps are subject to the Security Bug Fix Policy for Marketplace apps and must respond to reports of missing security requests in a timely manner.
If you’d like to check your apps yourself, or scan any new apps before listing them on the Marketplace, you can use open sourced versions of these new scanners using the documentation at CSRT and Connect Vulnerability Scanner repositories.
Prepare for Atlassian’s latest Connect app security scanners with new open source scanners for Signed-install AuthN, AuthZ, Input validation(XSS), and Insecure storage of secrets.
Atlassian regularly releases new cloud app security requirements and scanners to increase the baseline of security across all cloud apps and protect our shared customers from security risks.
Don’t get caught missing a requirement! Prepare for Atlassian’s latest Connect app security scanners with new open sourced scanners for Signed-install AuthN, AuthZ, Input validation(XSS), and Insecure storage of secrets.
Should we find a missing requirement, we will notify you via the Atlassian Marketplace Security Jira Project. As a reminder, all apps are subject to the Security Bug Fix Policy for Marketplace apps and must respond to reports of missing security requests in a timely manner.
Marketplace Partners with access to the Partner Portal can find the new scanners and more information here in the Partner Portal.
Developers can now lint the hasServiceManagementAccess permission in Display conditions. This permission replaces the previously used hasServiceDeskAccess.
This change will take effect on July 18, 2023.
For Jira Cloud customers, we advise not to grant “Browse Projects“ permission to "User custom field value (XXXX)", “Current Assignee“ or “Reporter“ fields in permission schemes to limit issue access, which will make all issues in the project accessible to the user.
Configuring issue-level security is the recommended approach to manage issue access. See Limit users to only browse issues assigned to/reported by them in Jira Cloud documentation for more details.
We’ve released real-time issue events. This means that the issue view will refresh if an update happens in the background. In addition, apps can now listen to a frontend event and refresh their UI to react to a given change. To learn more, look at the events section of issue view-related modules, such as Jira issue action.
The previous announcement of "IssueType will support hierarchy levels ≥ 1" has been updated such that the rollout of this functionality will continue until Sep 30, 2023, so using it in the production environment until then is not recommended. Re-read the announcement by visiting https://developer.atlassian.com/cloud/jira/platform/changelog/#CHANGE-876.
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."