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 inform you that we’re making the following new API endpoints available:
Returns a paginated list of priority schemes
GET /rest/api/3/priorityscheme
Get available priorities by priority scheme
Returns a paginated list of available priorities to be added to a scheme
GET /rest/api/3/priorityscheme/priorities/available
Get priorities by priority scheme
Returns a paginated list of priorities
GET /rest/api/3/priorityscheme/{schemeId}/priorities
Get projects by priority scheme
Returns a paginated list of projects
GET /rest/api/3/priorityscheme/{schemeId}/projects
POST /rest/api/3/priorityscheme
PUT /rest/api/3/priorityscheme/{schemeId}
DEL /rest/api/3/priorityscheme/{schemeId}
Suggested priorities for mappings
Returns a paginated list of priorities
POST /rest/api/3/priorityscheme/mappings
Following the deprecation notice (see https://developer.atlassian.com/cloud/jira/platform/changelog/#CHANGE-916), the products
field will be mandatory for the Jira User Create REST API.
This change will take effect as soon as the new Create User API doc is released, expected within the next few days.
Valid product name for the products
field: jira-core
, jira-servicedesk
, jira-product-discovery
and jira-software
. To create a user without product access, set this field to be an empty array.
The UI modifications (UIM) module now supports three new entry points for the issue view:
list
issues
search
The complete list of supported entry points is available here.
Atlassian Security Scanner is already checking your Marketplace apps for any critical- or high-severity vulnerabilities in third-party dependency trees and .jar
files. The tool is helping us ensure that all apps on the Marketplace are safe for our customers to download and install on their instances.
While .jar
files are scanned every day due to the nature of modern cyber threats, third-party dependencies are checked when you submit your app for approval for the first time and during the regular annual review.
If Security Scanner doesn’t detect any vulnerability in your app, it’s safe to be on the Marketplace.
In case a security issue has been found, a Jira ticket about it will be created in the Atlassian Marketplace Security (AMS) project, and you’ll receive an automated email notification about the ticket. As soon as you fix the issue, upload the new version of your app to the Marketplace. Your ticket will be closed automatically the next day after Security Scanner checks the app again and finds no vulnerabilities.
If you need help or have questions, don’t hesitate to chat with an entitled representative of the Data Center Review team in the ticket’s comments. Or you can always contact Atlassian Support directly.
We’d like to highlight that the security scanning on our side is a complementary process to catch the most obvious security issues in case there are no security processes established on the app partner’s side. Thus, our solution doesn’t aim to substitute security checks on your side with a tool you trust. We rather provide assistance with a security audit in case these checks aren’t done.
The UI modifications (UIM) module now supports new fields on the following views:
The complete list of supported fields for the issue view is available here.
We have now fixed the incorrect scope check requests with a trailing forward slash.
Assume there is a scenario where a request is made to an endpoint https://api.atlassian.com/some/path/
. Scope checking may find a valid scope for path /some/path/**
and pass the scope check. Once the request reaches the backend service, if the service does not have a path with a trailing slash, it may remove it and invoke the parent endpoint https://api.atlassian.com/some/path
which may not have the same scope requirements.
With this fix, scope checking will ignore the trailing slash when matching scopes to the path.
This means that a request to https://api.atlassian.com/some/path/
and https://api.atlassian.com/some/path
will be treated the same with respect to scope checking.
We are announcing the deprecation of two Jira Web Panel (webPanels
) module locations within Forge or Connect applications. The affected locations are:
atl.jira.view.issue.left.context
: For web panels that appear in the content section on the left. We advise transitioning to the Issue Context module for similar functionality.
atl.jira.view.issue.right.context
: For web panels that are displayed in the context section on the right, resembling a glance panel. We recommend migrating to the Issue Context module for these needs.
This change means that if your Forge or Connect app currently utilizes these two Jira Web Panel (webPanels
) module locations, it is essential to migrate to the issueContext module. Detailed guidance on adopting the new Issue Context API is available in our documentation.
The progressive rollout of data security policy events has been completed. 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. You can now subscribe to these events.
Being a new capability however, we are scaling up our processing of these data security policy events over the next few months. In the meantime we have set a upper limit of 50,000 objects. This means that if a customer activates or updates a data security policy that affects more than 50,000 objects, you will receive the first 50k objects in the events and the rest would be omitted.
We intend to raise these limits and will advise once we have reached our final threshold— and have determined our final hard limits.
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.
The new app access rule under data security policies allows customers to restrict app access to the content in Confluence spaces or Jira projects under a given policy. In this way, customers can benefit from apps while still limiting 3rd-party app access to certain content in select spaces.
If you are looking to update your apps with custom in-app messaging whenever your app is affected by an app access rule, we encourage you to use the Developer guide.
Currently, in company-managed projects, JQL searches with hidden fields (either by custom field context or field configuration) won’t return any results. In team-managed projects, all fields are searchable and appear in search results.
To improve search performance, we’re changing the search of company-managed projects to match that of team-managed projects: in both project types, all fields will appear in search results whether they’re hidden or not. This means that when you use a JQL search with a hidden field in company-managed projects, issues with that hidden field will now show up (when they previously wouldn’t).
This change only affects about 2% of all searches, but depending on how you use JQL, some of your filters in company-managed projects may return different results.
Be specific about the project
and/or issue type
you want to see - or hide - in the JQL search results.
For example, if fixVersion
is hidden for issue type = "Story"
and you want to exclude it from search results, use issue type != "Story"
to get focused results.
If you’re not specific, any hidden fields will be included in the search results.
We’re launching this by the end of September 2024.
In the past, dashboard background scripts were rendered only if at least one dashboard gadget from the same app was present on the dashboard. This behavior has changed. Now, dashboard background scripts are always rendered.
As of this week, some Cloud customers will be able to set up and enable app access rules under data security policies. The feature will be slowly rolled out to customers over the coming week.
Customer outreach for this feature will be high-touch at first to give Marketplace Partners more time to update apps, but we plan to do a larger announcement toward the middle of 2024 (calendar year). You can read more about the rollout plan here.
We highly recommend testing out the feature and considering adjusting your app to warn users when it’s impacted by an app access rule.
Prepare for this change by reading more about the app access rule API here for Jira and here for Confluence.
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.
The new app access rule under data security policies allows customers to restrict app access to the content in Confluence spaces or Jira projects under a given policy. In this way, customers can benefit from apps while still limiting 3rd-party access to certain content in select spaces.
Databases are currently in beta and Smart Links in the content tree are being generally rolled out as of April 2nd. In Progress
Endpoints and scopes have been added for Confluence Smart Links in the content tree and Databases. For further information about these updates, reference the Atlassian Developer Documentation for OAuth and Forge scopes as well as Confluence Cloud REST API v2.
Three new scopes have been added for each: read
, write
, and delete
. These additions will support the implementation of Smart Links and Databases in Forge applications.
Read | Write | Delete |
---|---|---|
|
|
|
|
|
|
Creation, retrieval, and deletion of Smart Links in the content tree and Databases have been added for v2 REST APIs. Creation, retrieval, modification, and deletion of properties
as well as retrieval of operations
and ancestors
is supported via these added APIs.
We have started the rollout of data residency for Forge hosted storage, where data will be moving to the same location as the host product. To ensure a smooth rollout, we will be rolling out the feature to customers gradually over the next month.
Once the rollout is complete, Forge hosted storage data will be stored in the same location as the host product for all new and existing Forge apps, for all current and future Atlassian-supported locations. We will let you know when the rollout is complete.
Action Required
Last month, we outlined some actions required to prepare for this rollout (see changelog for more information). If you haven’t done so yet, we recommend:
redeploying any app that uses Forge-hosted storage
updating the manifest for any apps that use remotes or external permissions (for details about how to do this, see our documentation).
At the end of the staged rollout, we also recommend updating the Privacy & Security tab for any app that exclusively uses Forge hosted storage for in-scope End User Data, to indicate that your app supports data residency. You should also define in your app documentation what data is in-scope and out-of-scope. This way you can let customers know about your app’s support for data residency. We will let you know when to make this update.
Data residency for Forge-hosted storage is the latest milestone on our shared mission to offer enterprise-ready apps to customers in the cloud. With data residency available for Forge-hosted storage, meeting a key customer trust requirement will be easier than ever.
It’s important to note that, as we shared last November, when data residency reaches beta for Forge-hosted storage, app data stored in Forge-hosted storage will automatically inherit data residency in all current and future regions supported by the host product. This will not be reversible.
We’re updating the deletion of issue field options used in issues for consistency across the Issue field options and Issue field options (apps) endpoints. We recommended that you utilize the new replace issue field option service.
We're updating the DELETE issue field option REST operation, which will return a 409 Conflict
status when you remove an option that is used by issues.
Additionally, we’re introducing a new endpoint to simplify the transition by allowing options to be replaced. This new feature is similar to the existing Replace issue field option (apps) function.
To improve the consistency of the deletion process across Jira. With this change, we aim to enhance developer experience and enable enhancements on our platform infrastructure.
We recommend that you use the new replace issue field option service. You can use this service to update any issues associated with a specific issue field option before its deletion. This avoids potential 409 Conflict
errors when calling the DELETE issue field option REST operation.
Additionally, leveraging Search for issues using JQL (GET) can help identify any instances where an issue field option is used prior to its removal.
In the coming 2 weeks, all Cloud customers will be able to set up and enable app access rules under data security policies. Customer outreach for this feature will be high-touch at first to give partners more time to update apps.
Many app components will display proactive warnings letting customers know that the app has been blocked by their admin. However, if an app relies on data from restricted spaces or projects, user experience may be impacted in other spaces where the app is not blocked. This may confuse end users or present them with incorrect data if the app is not adjusted to account for the impacts of app blocking.
For this reason, we highly recommend testing out the feature and considering adjusting your app to warn users when it’s impacted by an app access rule.
Prepare for this change by reading more about the app access rule API here for Jira and here for Confluence.
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.
The new app access rule under data security policies allows customers to restrict app access to the content in Confluence spaces or Jira projects under a given policy. In this way, customers can benefit from apps while still limiting 3rd-party access to certain content in select spaces.
Rate this page: