This changelog is the source of truth for all changes to the Forge platform that affect people developing Forge apps.
Posts are made in the Forge announcements category of the developer community when the changelog is updated. Subscribe to the Forge announcements category to get notifications.
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 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 happy to announce the GA release of Forge remote. This includes the ability to:
As mentioned in the previous announcement, if your Forge app has the bitbucket:mergeCheck
module, it needs to include the read:pullrequest:bitbucket
scope.
This is now enforced at runtime. If you deploy an app containing bitbucket:mergeCheck
module without the read:pullrequest:bitbucket
scope, the app’s mergeCheck functions will fail to be invoked.
Make sure that you:
Update your app manifest.
Redeploy via forge deploy
.
Update the app installations via forge install --upgrade
.
When creating custom merge checks for Bitbucket Cloud, you can now use a remote endpoint
in place of a hosted function
.
You can optionally configure your https://developer.atlassian.com/platform/forge/manifest-reference/endpoint/ to receive an appSystemToken
which can be used to make API requests back to Bitbucket APIs and Forge storage.
See https://developer.atlassian.com/platform/forge/forge-remote-overview/#remote-delivery-of-product-events--lifecycle-events-and-scheduled-triggers for more information.
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.
We document a list of IP address ranges for outbound connections for Forge apps. These IP address ranges allow Forge apps to make connections through firewalls or integrate with software that has a managed IP allowlist.
In line with improving performance across more regions, we added more compute servers for Forge. As a result, we added more IP addresses to this list.
If you plan to use these IP address ranges, it’s important that you monitor Atlassian’s documentation for changes to this range. A JSON file containing this information is published to https://ip-ranges.atlassian.com/, which may aid automation.
Note: Per-app IP allow listing is still not supported
The IP address range for outgoing connections is shared by all Forge apps. Allowing connections from this IP address range will permit connections from any Forge app.
We originally published this list on Sep 19, 2023, and it’s now grown:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
52.195.248.93/32
54.65.219.119/32
43.207.238.123/32
3.114.146.111/32
54.248.180.178/32
57.180.171.119/32
13.209.252.121/32
15.165.21.19/32
43.202.223.238/32
3.34.8.241/32
3.37.121.177/32
3.34.165.169/32
15.164.153.22/32
43.201.237.75/32
13.200.51.21/32
13.200.127.18/32
65.2.173.31/32
15.206.230.70/32
3.7.242.212/32
43.205.183.186/32
54.255.41.156/32
52.77.196.9/32
18.143.11.169/32
18.142.175.136/32
54.254.13.217/32
52.220.108.50/32
3.104.191.162/32
13.238.244.22/32
3.106.172.84/32
52.65.164.184/32
13.237.143.132/32
3.105.255.118/32
3.98.151.27/32
3.96.73.34/32
35.182.178.44/32
15.156.32.59/32
15.222.164.249/32
15.156.255.184/32
18.153.162.220/32
18.157.151.173/32
3.126.237.94/32
18.196.69.189/32
52.58.86.18/32
3.77.185.155/32
16.63.156.232/32
16.63.10.60/32
16.63.133.73/32
16.63.192.113/32
16.63.86.27/32
16.63.153.19/32
54.220.63.40/32
54.154.186.82/32
52.208.56.204/32
54.76.137.153/32
34.253.103.242/32
63.34.104.55/32
13.43.10.138/32
18.132.72.151/32
13.43.238.10/32
13.43.230.20/32
13.42.94.26/32
13.41.178.119/32
18.229.170.213/32
54.232.43.18/32
52.67.212.82/32
54.94.144.45/32
15.229.167.123/32
177.71.171.149/32
3.224.137.93/32
52.55.61.132/32
54.156.218.101/32
34.194.247.143/32
3.220.210.28/32
34.231.161.126/32
34.194.73.28/32
3.231.15.71/32
54.241.128.19/32
13.56.84.222/32
52.53.140.163/32
54.193.160.145/32
54.218.196.28/32
35.160.6.102/32
18.236.52.165/32
52.43.192.52/32
34.215.254.205/32
54.214.155.219/32
54.190.195.254/32
52.89.100.78/32
Following the deprecation notice, we’ve deprecated jiraIssueGlances
and jira:issueGlance
as we have replaced with issueContext
module.
With the release of the upgraded @forge/react version 10, we’ve created a guide that outlines the breaking changes for existing UI Kit 2 apps. We recommend you review the updated documentation to understand the differences and the effort required to upgrade your app.
Upgrading to the latest version may contain breaking changes for existing UI Kit 2 apps, as all existing component APIs have been updated. The breaking changes are only applicable if you choose to upgrade your UI Kit 2 apps.
Starting at the end of March 2024, all Cloud customers will be able to set up and enable app access rules for Jira and Confluence under data security policies. This change will give customers an important new control to protect data while benefiting from Marketplace apps.
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 (ex: search features or workspace modules) 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 adjusting your app if necessary to warn users when it’s impacted by an app access rule.
Prepare for this change by reading more about how applying an app access rule to your app affects the behaviour of product REST APIs it calls 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.
The UI modifications (UIM) module now supports the date time picker custom field in two new locations: global issue create and issue view.
You can now view a detailed breakdown of API metrics directly in the developer console. This is handy when you’re debugging client or server errors or if you’re wanting to gain insights around the performance of the APIs your Forge apps are using.
API metrics are available for all function
invocations making either Fetch API, Async events API, and Web trigger API, or Storage API HTTP requests.
The image below shows the detailed view for 4xx - Client errors.
The image below shows the detailed view for API response time.
Forge apps using the bitbucket:mergeCheck
module will now require the read:pullrequest:bitbucket
scope in their manifest.
When deploying an app, if the read:pullrequest:bitbucket
scope is not in the manifest, the forge deploy
command will fail.
In a few weeks, the read:pullrequest:bitbucket
scope will be enforced at runtime. This means that, if the scope is not present in the deployed and installed version of an app, the app checks function will fail to be invoked.
In preparation for this change, we recommend:
deploying the app with the additional scope to each environment, production included
install the deployed version of the app via forge install --upgrade
to every workspace for each environment
apps distributed to customers will need to be upgraded by following the steps here: https://developer.atlassian.com/platform/forge/distribute-your-apps/#share-an-app-update
Another changelog will be posted when the scope is enforced at runtime.
If you have any questions, please add a comment to the community post.
As part of our preview release of Forge UI Kit 2, we're releasing a new major version of @forge/react
with 37 updated components.
From version 10 onwards, existing component APIs are now updated, and a range of new components are now supported in UI Kit 2. For more details, see our documentation here.
The new version is supported within the following products:
Confluence
Jira
Bitbucket
Compass
Updating to the latest version may contain breaking changes for existing UI Kit 2 apps, as all existing component APIs have been updated. The breaking changes are only applicable if you choose to upgrade your UI Kit 2 apps.
Our component documentation contains more details on the props each component will now take.
To update your UI Kit 2 app to the latest version, in the terminal from your project directory, run the following command:
npm install --save @forge/react@latest
If you’re still using older versions of UI kit, such as the previous version of UI Kit 2 (@forge/react version 9) and UI Kit 1, you can find their corresponding documentation here.
This week we have started the progressive rollout of data security policy events generated when an app's access to certain data within Confluence, Jira Cloud, Jira Service Management, or Jira Software has been blocked by an App access rule. These events are available to subscribe to today, for App Access Rule EAP participants.
Being a new capability however, we are scaling up our processing of these events over the next few weeks. Initially only a sample of events will be sent and we will be increasing the sample progressively, aiming for 100% of events (with an upper cap) by the time the feature reaches General Availability at the end of March or early April.
Note that not all apps registering a webhook for these events will necessarily receive a sample of events, but most will.
Over the next month we will be raising these limits and will share details here once we have reached our GA threshold - and what our final hard limits are.
We have updated Remotes documentation to clarify that a change made to an existing remotes baseURL
will continue to trigger a major version upgrade. This has been the expected behaviour and has not changed.
Rate this page: