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 createFrame helper function simplifies the communication between the UI Kit and Frame components. It enables the creation of custom Frame components with support for passing custom properties from UI Kit to Frame component resources as simple React component properties.
For more information about how to use the createFrame helper function, see here.
The upper limit of for Data security policy events has been increased to 200,000 objects, from the previous limit of 50,000 objects.
How does the upper limit work
This means that if a customer activates or updates a data security policy that affects more than 200,000 objects, you will receive the first 200k objects in the events and the rest would be omitted.
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.
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. App developers can subscribe to these events, we encourage you to read the Developer guide.
As we deprecate less secure and older cipher suites, some customers using Basic Authentication may experience connectivity issues between Jira and connected email accounts due to the “Remote host terminated the handshake” error. As a result, your service project may not receive requests and comments from incoming emails to Jira. This change will take effect on August 5, 2024.
To avoid disrupting these incoming emails, you must review your existing email server configurations and ensure they use one of the supported TLS cipher suites. The process may vary based on the email server software you’re using.
The Developer Assistant App, which manages the Developer Canary program, will require additional permissions to function, and therefore all users must approve an update manually.
Atlassian is changing the tools and processes we use internally to manage and roll out changes. We have released a new version of the Developer Assistant App to adapt to this. The old version of the app will stop working after Dec 1, 2024 . All instances currently enrolled in the Developer Canary program will stay enrolled, however you will need to install the new version of the Developer Assistant app to change your enrollment status.
This follows an RFC detailed in this Developer Community thread.
For more information about the Developer Canary program, or installing the Developer Assistant App, please see this page.
On Jul 30, 2024, we will begin rolling out a fix for Forge apps which declare the Connect lifecycle module to use a distinct shared secret that changes on major versions instead of a single shared secret like it is currently.
The history of why we are making this change and why we want to move to this secret model is outlined here. If you’ve followed the previous post, we expect no functional changes for app developers. Please ensure your apps are storing and maintaining secrets on a per-installation basis.
On Jul 30, 2024, new Connect on Forge app installations, major version upgrades, and Connect to Forge migrations will start receiving distinct shared secrets.
After Aug 7, 2024, we will be rotating the secrets of existing Connect on Forge app installations to move them to distinct shared secrets. A new installation payload containing this secret will be shared.
These changes will be rolled out on a per-tenant basis.
Connect apps adopting Forge can now register, retrieve and delete new and existing dynamic modules.
For more information, refer to Incrementally adopting Forge from Connect.
Connect apps registered on Forge are no longer able to set `app.connect.authentication: oauth2` in their manifest. This caused client credentials to be sent in the installation hook that could be exchanged for an api.atlassian.com access token. Developers wishing to make requests to api.atlassian.com from their app server should use Forge Remote instead. If you were relying on this feature, we’re happy to answer questions you may have about migrating on the Developer Community forums.
We’ll be introducing a change to the schema of Forge issue worklog product events (created / updated).
Specifically, the author and updateAuthor fields of Worklog will no longer be mandatory.
To give you ample time to adjust, we're providing a 6-month deprecation period for the schema.
Therefore, the change will take place on Jan 8, 2025.
The schema for the Worklog entity will change from:
1
2
3
4
5
6
7
8
9
10
11
interface Worklog {
id: string;
issueId: string;
author: User;
updateAuthor: User;
created: string;
updated: string;
started: string;
timeSpent: string;
timeSpentSeconds: number;
}to
1
2
3
4
5
6
7
8
9
10
11
interface Worklog {
id: string;
issueId: string;
author?: User;
updateAuthor?: User;
created: string;
updated: string;
started: string;
timeSpent: string;
timeSpentSeconds: number;
}making the author and updateAuthor fields optional.
Note that this means that the author and updateAuthor may be missing from the payload when a worklog is created or updated by an anonymous user.
Forge functions can now interact with remote backends utilising Forge Remote. This capability makes it simpler and more secure to integrate remote backends with your Forge app.
See Forge Remote - Calling a remote backend from a Forge function for more information.
UI Kit data visualizations components are in Early Access Program (EAP).
We now have the following data visualization components to organize and present data:
Bar chart
Stack bar chart
Horizontal bar chart
Horizontal stack bar chart
Line chart
Pie chart
Single value
To start using this EAP, sign up using the Forge EAP form.
For more information about how to use the components, see here.
We’re happy to introduce a new batch of Jira Forge product events for the following entities:
Project (deleted)
Issue (deleted)
Attachment (deleted)
Comment (deleted)
Worklog (deleted)
Follow the links to read more about them.
The Frame component is now in Early Access Program (EAP). Frame allows you to load custom resources within UI Kit, making it easy to import non-UI Kit components in a UI Kit module.
To start using this EAP, sign up using the Forge EAP recruitment form.
For more information about how to use the Frame component, see here.
We have now fixed the issue where the forge deploy command was unable to bundle the app when entry points are configured with different resource types (Custom UI and UI Kit). This was particularly seen for modules supporting multiple entry points, such as https://developer.atlassian.com/platform/forge/manifest-reference/modules/jira-custom-field/#jira-custom-field.
Plan-only teams (also known as private teams) can no longer be used outside of an Advanced Roadmaps plan, specifically in the Team field via Jira REST APIs and JQL queries.
Plan-only teams (also known as private teams) are no longer usable outside of an Advanced Roadmaps plan, specifically in the team field via Jira REST APIs and JQL queries.
Plan-only teams were never provided as JQL suggestions for the team field. However, it was possible to query a plan-only team directly by its ID. Since this change, querying plan-only teams directly by ID doesn't return any results.
Plan-only teams are no longer exposed in the team field of an issue on the Jira Get Issue REST API, nor are they settable via the Create or Edit Issue REST API. Previously only the ID and the placeholder title “Plan-specific team" were returned.
All functionality for Atlassian teams will continue to be supported.
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.
Rate this page: