Changelog

Forge app names can now be up to 60 characters when:

• Set via the Forge CLI, or

• Updated in the Developer Console.

Previously, Forge app names were limited to 50 characters, while Marketplace listing names could be up to 60 characters in length.

Following our recent preview release of Forge UI Kit 2, we're excited to announce that UI Kit 2 is now generally available. With this release, UI Kit 2 has been promoted as the latest version of UI Kit and will now be referred to as simply UI Kit.

For more detailed information on using UI Kit components to design and build apps, please refer to our UI Kit components documentation.

The latest version is supported within the following products:

• Bitbucket

• Compass

• Confluence

• Jira

• Jira Service Management

With Forge UI Kit now generally available, we’re releasing a new major version of the Forge CLI.

Here’s a summary of the CLI changes:

• We’ve renamed UI kit 2 (Preview) template option to UI Kit.

• We’ve removed the original UI kit template option. This means no new UI Kit 1 apps can be created with this latest version.

To install the latest version, in your terminal, run: npm install -g @forge/cli@latest

We have now added the following rate limits to WebTrigger GraphQL operations:

• createWebTriggerUrl - 500 requests / 60 seconds

  • This include usage of the webTrigger.getUrl method from the @forge/api NPM package.

• deleteWebTriggerUrl - 500 requests / 60 seconds

• webTriggerUrlsByAppContext - 1000 requests / 60 seconds

Each limit is applied with the following dimensions: appId + site + forge app environment + userId.

For more information, see https://developer.atlassian.com/platform/atlassian-graphql-api/graphql/#rate-limiting.

The UI modifications (UIM) module now supports new fields on the following views:

• Parent

• Components

• Reporter

• User picker

• Multi user picker

• Parent

The complete list of supported fields for the issue view is available here.

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.

The Forge confluence:spaceSettings module now supports view.createHistory() for Custom UI via @forge/bridge. App developers can now utilize a path segment at the end of the global page URL to maintain page history within their application.

The Forge Cache API is now in EAP. This API offers high throughput and low-latency cache for ephemeral data storage. For more information about the EAP, here. To sign up and start testing, click here.

Previously, calling asUser from @forge/api without a user context for the invocation (e.g. a webtrigger or trigger) would result in an internal NeedsAuthenticationError being thrown.

In the the native Node.js runtime this will now throw a ProxyRequestError with errorCode AUTH_TYPE_UNAVAILABLE.

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.

Today we are starting the gradual roll out of a new, modern look for macros in Confluence Cloud’s editing experience, available to sites in the Developer Canary Program and a portion of customers. This will be more aligned with the design of other elements, and make macros more WYSIWYG, i.e. appear more like they do in the viewing experience.
To see this in action, check out More details below.

You can now use Forge UI Kit 2 to build the user interface of your apps across Jira custom field and custom field type modules.

For more information on using UI Kit 2 components to design and build apps, see the UI Kit 2 components documentation.

Note that two new templates, jira-custom-field-csuik and jira-custom-field-type-csuik, are now available when running the forge create command in the Forge CLI. You can use these templates to create UI Kit 2 apps with the custom field and custom field type modules.

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:

1. redeploying any app that uses Forge-hosted storage

2. 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.