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’re happy to introduce a new Jira Forge product event:
Project version deleted - avi:jira:deleted:version
Follow the link above to read the event’s documentation.
UI modifications, the Forge module that allows apps to modify fields, now supports the original estimate field on the Issue view.
For more information, see the list of supported fields for Issue view.
Forge app templates for rovo:agent and actions are only available in Forge CLI 10.8.0 and later versions.
Run npm install -g @forge/cli@latest on the command line to install the latest version of @forge/cli.
Note: This change won’t impact any existing apps.
The navigation changes to Jira, JSM, JPD, and Atlassian Home have now moved from EAP to Beta. For partners, this is an extension of the previously announced EAP. This extended EAP will enable partners to test the new navigation and assess how apps will adapt to the proposed changes. Unlike the previous EAP, the design direction is now near final, so we recommend partners start adopting the new navigation.
As part of the extended EAP, we’ve set up a dedicated group on CDAC where you can discuss these changes. To join the beta launch, register through the EAP form.
Please visit the community post https://community.atlassian.com/t5/Navigation-Refresh-articles/What-s-changing-in-Apps-with-Atlassian-s-Beta-launch-of-New/ba-p/2871925 where you will find detailed information about the changes, recommendations, and a comprehensive FAQ section tailored for our partners.
Jira Forge now supports string, object, and number custom fields on the new Transition view. Note that you have to enable the view on your instance to be able to use it.
For more information about the Transition view, go to our documentation.
We enhanced external authentication with new options that let you:
Use HTTP basic authentication with the authorization server.
Customise HTTP requests for some actions.
Use string interpolation and customise HTTPS methods and query parameters for a static profile retriever.
All partners in the Developer Canary Program can now test their apps with live pages! Note that live pages are still in early access, and customers that opt in are aware that some apps may not be fully functional yet in live pages. Starting January 2025, we will start gradually rolling out the ability to opt in to the live pages beta to more customers (expecting to be available for opt in for all customers by April 2025).
To get started with testing live pages, follow the instructions here: Create and collaborate on live pages in Confluence. We also announced this in the developer community, where you can leave comments & feedback. See our community announcement here.
See More details, for more technical details & things we recommend you try.
We recommend making sure that your app works in live pages that may never be published and always remain live pages. Keep in mind that live pages can still be published (e.g. for use cases like knowledge bases), so make sure that your app still makes sense with published pages--both while viewing & editing them.
Continue to consider permissions scenarios around who can edit / view pages, these continue to exist in live pages (e.g. a user may have view-only permission of a live page).
Live pages will support the following page extension points. If you are using any other extension points, we recommend you migrate so that your app is accessible in live pages. As stated on October 31, 2024, we will be deprecating other Confluence page extension points (note that extension points beyond pages are unaffected). Learn more about the extension points we are deprecating here.
Forge
confluence:contentBylineItem
confluence:contentAction
confluence:contextMenu
Connect
system.content.action/secondary
contentBylineItem
system.content.action
system.content.action/primary
atl.general
system.content.action/modify
page.view.selection/action-panel
system.content.action/marker
atl.footer (will not render a UI component, but can still be used for running background scripts)
Bodied Macros (COMING SOON)
In December, we plan to rollout changes that make Bodied Macros like Table Filters & Aura Tabs functional in live pages. Today while editing, bodied macros only display in their “Edit” state--a text box where users can enter rich Confluence content. Users must publish to see macros in their rendered “Display” state. We will be giving users the option to switch between these “Edit” and “Display” states freely within the Editor without publishing, making them functional in Live Pages.
When inserting a bodied macro, users will see the “Edit” state of the macro by default, so they can add content. They will need to exit the “Edit” state to see the “Display” state – now, they won’t need to publish & scroll around to see the “Display” content.
When viewing a page with a bodied macro, users (assuming they did not insert the macro themselves) will see the “Display” state by default. They will be able to hover on the macro and enter the “Edit” mode.
We will let you know when we release these changes and we recommend testing your apps then to make sure they work as expected.
Non-Bodied Macros
As discussed in RFC-50, we’ve made it so non-bodied macros like Gliffy and draw.io, are more easily interacted with AND configured in the Editor, both for live pages & classic published pages. This has also been referred to as “removing the glass pane” from macros while editing. We recommend that you test your non-bodied macros in live pages to make sure they work as expected.
Since live pages do not have drafts and are not explicitly published, there are updated events for them. Note that live pages can still be published, which turns them back into standard published pages.
Webhook Key | Forge Event | Description |
|---|---|---|
|
| Emitted at the end of the first editing session of a page. The page will have a user generated title and 1 version. |
|
| Emitted at the end of every subsequent editing session. |
Currently, Live pages and draft/published pages will be differentiable via the content API by the subtype field. Currently the subtype is not available on the v2 API. This is not considered a stable API.
In the near future, we will make the subtype field available on the v2 content API, making it a stable API.
Currently, a new version is created at the end of the “editing session”, which occurs 15 minutes after the users finish making changes.
In the near future, this logic will change such that the new version is created immediately once a user makes changes, but this version will remain in flux as users make changes, and only finalized 15 minutes after the editing session ends.
Previously, when copy pasting a Forge macro within a Confluence page, the macro’s localId would stay the same, losing its uniqueness within the page.
Now, when copy pasting a macro, a new localId will be generated. Existing macros will be unaffected.
In further detail:
Any macros copy + pasted from this point onwards will receive a newly generated localId
Any existing macros with duplicate IDs will not be affected
This is because changing these IDs has the possibility of altering the user’s view of the page, if apps are storing data keyed against this ID
The only caveat to the above is:
Cutting and pasting a pre-existing duplicated macro also triggers the paste logic, and will result in a new localId being generated
This does not apply to using the handles in the Confluence UI to drag the macro to a new position
Note that localIds are only expected to be unique within a given page, so if you wish to have a globally unique ID across the entire site, you should continue to use a combination of content.id and localId.
Because of this, copying and pasting a macro from one page to another will not result in the ID being regenerated, unless that ID is no longer unique on the new page (such as the macro being pasted from another page multiple times).
Long-running functions are now available as an Early Access Program (EAP) feature for Forge.
This feature allows developers to configure functions for Forge async events that have a much high maximum duration of 15 minutes (up from 55 seconds). This can be useful for apps that need to perform complex, batch operations or for apps that need to perform long-polling against external services. This EAP may also be relevant for developers performing data processing as part of their server-to-cloud app migration.
Refer to the Forge documentation for the function module and the async events API for more information about this new capability.
To sign up for this EAP, use the request form.
You can now execute git operations from Forge remote backend of a Bitbucket Forge app using app system or user tokens. See Forge remote documentation for details.
The Confluence cloud navigation changes are now available in EAP. This Early Access Program will enable partners to test the new navigation and assess how apps will adapt to the proposed changes.
As part of EAP, we’ve set up a dedicated group on CDAC where you’ll be able to discuss these changes. Please note that the designs in the EAP are not final, so you are NOT expected to make any changes to your apps during the EAP. For partners who previously expressed interest, the new navigation will be activated to the test instances today.
To join this Early Access Program, register using the EAP form.
See RFC-59 for more information on Confluence Cloud navigation changes
You can now migrate existing Connect dashboard items to the Forge dashboard gadget module.
This change allows your app to render existing Connect dashboard items as Forge dashboard gadgets when you adopt a Forge gadget with a key matching the Connect dashboard item.
See Migrate Jira modules from Connect to Forge for more information, including how to preserve the Connect dashboard item’s data when migrating it to a Forge module.
As mentioned in the previous announcement, we have modified the functionality of the forge logs -n <limit> and forge logs --limit <limit> CLI commands for Forge CLI version 10.9.0 (or higher). Instead of showing logs from the last <limit> invocations, it will show the last <limit> log lines.
This is a non-breaking change. While the behavior of the -n argument is changing, existing setups will not be affected.
We’re happy to introduce new Jira Forge product events for users:
user created - avi:jira:created:user
user updated - avi:jira:updated:user
user deleted - avi:jira:deleted:user
Follow the link above to read more.
Forge functions on Forge Remote is now generally available. 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.
Rate this page: