This changelog is the source of truth for all changes to the Forge platform that affect people developing Forge apps.
See what's next for Forge on our platform roadmap.
We're excited to share that Forge, our app development platform for Atlassian cloud products, is now generally available. You can rely on Forge's hosted infrastructure, storage, and FaaS functions to support apps in production; all of which are backed by Atlassian's operational readiness. Learn more about building the next Marketplace hit with Forge.
Note that some functionality in Forge remains in beta while we're still making changes that may break your apps. Learn more about the current functionality in beta.
We’ve introduced the following improvements to the Installation page in the developer console:
You can now view the dates when your app was first installed, for all its current installations.
You can now view logs associated with particular installations of your app. This is handy for faster access and troubleshooting.
See View app installations for more details.
Following the preview release, we’re pleased to announce that the new experience of viewing app logs is now generally available. By default, you can now use the new experience when viewing app logs in the developer console.
You can contact support if you encounter issues when using the new experience of viewing logs.
We’ve introduced the following improvements to app logs in the developer console:
You can now search for app logs using trace id, invocation id, modules, and log messages.
When downloading app logs, you can now find trace id values in both .csv and .log formats.
See View app logs for more details.
We fixed a timeout issue with the Basic Fetch API that occurred when a port was specified in the URL for the Forge Node.js runtime.
The fix will be applied once you re-deploy your app.
The list of supported ports has not changed (see https://developer.atlassian.com/platform/forge/runtime-reference/#https-only for details). Requests containing unsupported ports will result in an error response.
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.
We added a new column to the forge install list, forge webtrigger, and forge install --upgrade commands. This column displays the major version installed on a site.
This change helps you quickly identify the major version of Forge app installations. No additional steps are required to see the new column; it will appear automatically when you run the commands.
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.
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.
In our preview release of Forge Remote invocations via @forge/api, several IDs provided in the context token for several parameters only contained a UUID and not the full ARI, which is inconsistent with the frontend @forge/bridge implementation.
These IDs have now been changed to ARIs, so the format is consistent across both invocation methods.
When you use invokeRemote from the @forge/api package, it will send a Forge Invocation Token to your backend server, containing context about the invocation. For details, see this guide on The Forge Invocation Token (FIT).
This context include the parameters app.installationId, app.id and app.environment.id. When accessing these parameters from a backend request (sent using @forge/api) as opposed to from the frontend (sent using @forge/bridge), these parameters were provided as bare UUIDs instead of ARIs.
We are fixing this issue to align the format to use ARIs for both use cases regardless of invocation method, so that it matches the documentation.
The below table illustrates the changes:
Key | Previous | Fixed |
|---|---|---|
|
|
|
|
|
|
|
|
|
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.
On Jul 8, 2024 we announced that we started migrating forge tunnel to Cloudflare from ngrok. As of today, all developers using forge tunnel on Forge CLI 10.1.0 have now been migrated to Cloudflare.
We strongly recommend that you upgrade to the latest CLI version (see Upgrading for more details). If you are using a firewall, you may notice new connections to Cloudflare's tunnel infrastructure. For forge tunnel to work, ensure these connections are allowed.
Older CLI versions will continue to use ngrok for forge tunnel (and, therefore, will still require an ngrok account). For more information, see Tunneling.
Today, we are starting the gradual roll out of a new selection / configuration control for macros in the Editor that will make it easier to configure macros while editing in Confluence, starting with sites in the Developer Canary Program and a portion of users. No updates or work will be required by app makers.
To see this in action, check out More details below.
Thanks to all who left feedback in the RFC!
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.
We will be gradually transitioning from ngrok to Cloudflare for the Forge Tunnel in the Forge CLI version 10.1.0 throughout this week. This migration means that the Forge Tunnel will use Atlassian-managed Cloudflare infrastructure, eliminating the need for developers to manage separate accounts, unlike with ngrok.
If you are using a firewall, you may notice new connections to Cloudflare's tunnel infrastructure. Please ensure these connections are allowed for tunneling to work. Older CLI versions will continue to use ngrok for Forge tunnels and will require the existing setup to be maintained. For more information, see tunneling.
Rate this page: