This page contains announcements and updates for developers from various products, platforms, and programs across Atlassian. It includes filter controls to make it easier to only see updates relevant to you.
To ensure you don’t miss any updates, we also provide RSS feeds. These feeds will take on any filters you applied to the page, and are a standardized way of keeping up-to-date with Atlassian changes for developers. For example, in Slack with the RSS app installed, you can type /feed <FEED URL> in any channel, and RSS updates will appear in that channel as they are posted.
Forge CLI 13.3.0 introduced a server-side manifest check as part of the new approval workflow. However, environment variables in the manifest.yml file were not being interpolated before being sent to the validation endpoint. This caused the linter to return false-positive MANIFEST_INVALID_RULE errors for valid manifests.
This issue is fixed in Forge CLI 13.4.0. The CLI now correctly interpolates environment variables before performing the pre-deployment manifest check.
Update your Forge CLI to version 13.4.0 or later by running:
1
npm install -g @forge/cli@latestFor more information on using variables in your manifest, see the manifest variables reference.
To learn more about why these manifest checks and approvals are required, see the documentation on major version upgrades.
You can now use UI modifications in the Jira Service Management (JSM) agent view. This is an extension of the existing jira:uiModifications module and covers the views your agents use inside a service project.
What's changing
UI modifications now support three specific agent views:
Global issue create (GIC) - viewType: GICAgentView
Issue view - viewType: IssueViewAgentView
Issue transition - viewType: IssueTransitionAgentView
The agent view supports the same fields and methods as equivalent Jira views but is tailored for service projects.
Key differences include:
Extension context: Exposes the requestTypeId of the work item.
Supported fields: The set of supported fields differs from the JSM request create portal view.
REST API: The UI modifications REST API (GET, POST, and PUT) now accepts these three agent view types. When configuring agent view contexts, portalId must not be set, and requestTypeId is optional (omitting it means the context is not scoped to a specific request type). One of projectId, issueTypeId, or viewType can act as a wildcard, with a maximum of one wildcard per context.
You can use view.getContext() to detect the current view type:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
import { view } from '@forge/bridge';
import { uiModificationsApi } from '@forge/jira-bridge';
uiModificationsApi.onInit(async ({ api }) => {
const context = await view.getContext();
switch (context.extension.viewType) {
case 'GICAgentView':
// Runs when an agent creates a work item in a service project.
break;
case 'IssueViewAgentView':
// Runs when an agent opens a work item in a service project.
break;
case 'IssueTransitionAgentView':
// Runs when an agent transitions a work item in a service project.
break;
default:
break;
}
}, () => []);No action is needed if you don't want to support the agent view. If you do want to add agent view support, simply define the context for the Agent View view types using the REST APIs – your Forge app will then be invoked automatically in the agent-specific views.
For more information, see:
• JSM UI modifications module documentation (to be attached)
• uiModifications API bridge (to be attached)
The rovo:mcp module has progressed from the Early Access Program (EAP) to Preview. This module enables Forge apps to expose https://developer.atlassian.com/platform/forge/manifest-reference/modules/rovo-action/ as tools that you can add to custom agents in Rovo Studio.
What's changing
Apps using the rovo:mcp module can now appear under Connected Apps in Rovo Studio. This allows makes configured actions available as tools for custom agents, enabling them to interact with external data and services.
What you need to do
If you were already using the module during the EAP, no changes are required.
To get started, add the rovo:mcp module to your Forge app manifest and configure the actions you want to expose.
Review the updated documentation for implementation details:
The installations page in the developer console has been redesigned to scale with large app install bases and to give you more control over how you view your data.
Key improvements include:
Performance at scale — the page loads quickly even with large install bases.
Configurable columns — hide, resize and reorder columns, and pin your most important column to suit your workflow. Your preferences are saved locally.
Improved search and page navigation — find specific installations faster with a more responsive search and cleaner pagination.
This feature is currently in Early Access. To participate, sign up for the EAP.
The Forge bridge invoke method now supports an optional metadata argument. This allows you to receive additional information about an invocation, such as rate limiting details, alongside the response.
What's changing
When you pass a metadata argument into the invoke function, it returns an object containing both a body field (the invocation response) and a metadata field. Any supported field set to true in the metadata argument will be returned within this metadata field.
Currently, rateLimitProperties is the only supported field in the metadata. This allows you to monitor rate limiting information for your invocations to better manage app performance and reliability.
Example usage:
1
2
3
4
5
invoke('getText', { example: 'my-variable' }, { rateLimitProperties: true })
.then(({ body, metadata }) => {
// Log metadata for debugging purposes
console.log(JSON.stringify(metadata));
}What you need to do
If you want to access invocation metadata, update your invoke calls to include the third metadata argument and handle the new response structure ({ body, metadata }).
Existing calls to invoke without the metadata argument remain unchanged and will continue to return the response body directly.
For more details, see the Forge bridge invoke documentation.
What's changing
You can now use a single manifest.yml file across different deployments while adapting your Forge Container services configuration based, for example, on the environment type (development, staging, or production). This allows you to optimize for cost or performance by overriding settings like memory or CPU for specific environments.
What you need to do
To start using environment-specific configurations, update your manifest.yml using the new overrides syntax. For detailed implementation steps and examples, refer to the Forge Containers manifest overrides reference.
Static Content Macros for Confluence on Forge are now available in Forge’s Early Access Program (EAP).
Render your Confluence macros as static content instead of iframes, reducing app invocations. To enable static rendering, sign up for the EAP and add the static property to your macro module in manifest.yml, specifying either a function or endpoint (for Forge Remote).
We’ve corrected how the maintenance (service) period is displayed on refund (credit note) rows in Marketplace reporting. Refund amounts are not affected — only the period dates have been updated to accurately reflect the full term covered by the refund.
This change affects the reported maintenance period dates shown on refund rows in Marketplace reporting. It does not change refund values.
Previously, refund rows in Marketplace reports could show a shorter maintenance period than the refund actually covered. This happened because the reported period was derived from a single line of the original invoice, rather than the full set of lines that made up the refund.
Because invoices are often split across multiple lines — for example, a short pro-rata segment plus the main annual term — the displayed period could be significantly truncated.
Example: A full one-year refund might have appeared as covering only 13 days.
With this correction:
The maintenance period on refund rows now reflects the full term covered by the refund, from the earliest start date to the latest end date across all constituent invoice lines.
Period dates are now sourced from our finance system of record, which correctly handles multi-year billing terms.
Refund amounts are unchanged. This update only corrects the reported period dates; no monetary values are affected.
The majority of refund rows, approximately 86%, were already displaying the correct period and will not change.
Review your reporting. If you use maintenance period dates from Marketplace reports to calculate period-based metrics, such as annualized revenue or daily run-rate, you may see changes for affected refund rows.
No action is required if you only use refund amounts in your reporting, because those values remain unchanged.
If your reporting uses only refund amounts and not maintenance period dates, this update should have no impact on your workflows.
Bitbucket Data Center and Server 9.4.23, 10.2.6, and 10.4.2 bug fix releases are available now!
To see the issues resolved in these bug fix releases, go to:
Starting September 2026, we are deprecating subscriptions on Atlassian Analytics dashboards.
What's changing
We are phasing out the ability to create and receive dashboard subscriptions in the following stages:
September 8, 2026: You will no longer be able to create new dashboard subscriptions.
November 2nd, 2026: The dashboard subscription will be fully removed for low-touch customers.
What you need to do
If you or your users rely on existing emailed dashboard reports, you should prepare for this feature's removal by November 2nd, 2026. We recommend exploring alternative ways to share data or transitioning to manual exports where available before the end-of-life date.
We’ve released the new adoption-status CLI command that analyses your manifest.yml and shows:
How much of your app has been migrated to Forge
Which migration requirements are complete
What remains to be done before you can finish your migration
From your Forge app directory, run:
1
npx @atlassian/connect-to-forge@latest adoption-statusNo installation is required.
If your manifest is in a different location, specify its path with the --manifest option:
1
npx @atlassian/connect-to-forge@latest adoption-status --manifest path/to/manifest.ymlFor detailed information about the command and its output, see https://developer.atlassian.com/platform/adopting-forge-from-connect/adoption-status-tool/.
The Forge Developer Console now provides visibility into build tags for your deployments. This update allows you to:
Identify if a specific tagged build was used for a deployment.
See if the most recent deployment to an environment used a tagged build.
To view the build tag for a specific deployment:
Navigate to the Deployments tab in the Developer Console.
Select the menu button and click more info under the actions column for the desired deployment.
To view the most recent tagged build for an environment:
Navigate to the Environments tab in the Developer Console.
Click on the date shown under the Last deployment column.
A new RFC is ready for review at https://community.developer.atlassian.com/t/rfc-142-confluence-migration-content-index-for-macros/102090 .
We are extending the Connect End of Support (EOS) date from December 2026 to January 31, 2027. This extension is intended to give partners and developers additional runway to complete their migrations without overlapping with end-of-year activities and annual planning cycles.
For more information, please read https://www.atlassian.com/blog/development/getting-ready-for-connect-end-of-support
The delay prop in the Spinner component from @atlaskit/spinner now keeps the spinner fully hidden until the delay elapses. Previously, a spinner with a delay painted a static, complete circle for the entire delay window before the fade-and-spin animation started, so short-lived loading states showed a stationary spinner instead of nothing.
No code changes are required. Apps that pass a delay to Spinner will see the intended behaviour after upgrading to the latest version of @atlaskit/spinner: nothing renders during the delay, and the spinner then fades in and spins as documented at https://atlassian.design/components/spinner/examples
Rate this page: