This page includes release notes and updates for Confluence Cloud app developers. Use this page to keep track of upcoming changes, deprecation notices, new features, and feature updates from Confluence Cloud.
For updates about changes to the Forge platform, see the Forge changelog in the Forge documentation.
You can also ask questions and learn from other Confluence Cloud developers on the Atlassian Developer Community.
We have now fixed the incorrect scope check requests with a trailing forward slash.
Assume there is a scenario where a request is made to an endpoint https://api.atlassian.com/some/path/. Scope checking may find a valid scope for path /some/path/** and pass the scope check. Once the request reaches the backend service, if the service does not have a path with a trailing slash, it may remove it and invoke the parent endpoint https://api.atlassian.com/some/path which may not have the same scope requirements.
With this fix, scope checking will ignore the trailing slash when matching scopes to the path.
This means that a request to https://api.atlassian.com/some/path/ and https://api.atlassian.com/some/path will be treated the same with respect to scope checking.
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.
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 app access to certain content in select spaces.
If you are looking to update your apps with custom in-app messaging whenever your app is affected by an app access rule, we encourage you to use the Developer guide.
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.
Some permission checks performed by the endpoint /wiki/rest/api/content/{id}/permission/check for operations other than read now return a different informational error message when a permission check fails, as follows:
Some checks that returned “User does not have permission to the space” now return “User does not have permission to the content”.
Some checks that returned “Anonymous user does not have permission to the space” now return “Anonymous user does not have permission to the space”.
Previously, this API did not return “User does not have permission to the space” consistently when the cause of a failed check was a lack of space permissions, so this change is not breaking. It simply reduces the frequency with which this message is returned as an error in the response body for operations other than read.
The endpoint /wiki/rest/api/content/{id}/permission/check provides error messages in the response if the user or group fails the permission check. These include the below four messages:
User does not have permission to the space
User does not have permission to the content
Anonymous user does not have permission to the space
Anonymous user does not have permission to the content
Calling this endpoint for operations other than read may not consistently return "User does not have permission to the space" or "Anonymous user does not have permission to the space" and may return "User does not have permission to the content"/"Anonymous user does not have permission to the content" even if the check failed due to a lack of space permissions.
Calling this endpoint with read for the operation parameter will generally still return “User does not have permission to the space” or ”Anonymous user does not have permission to the space” with about the same frequency as before.
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.
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.
Databases are currently in beta and Smart Links in the content tree are being generally rolled out as of April 2nd. In Progress
Endpoints and scopes have been added for Confluence Smart Links in the content tree and Databases. For further information about these updates, reference the Atlassian Developer Documentation for OAuth and Forge scopes as well as Confluence Cloud REST API v2.
Three new scopes have been added for each: read, write, and delete. These additions will support the implementation of Smart Links and Databases in Forge applications.
Read | Write | Delete |
|---|---|---|
|
|
|
|
|
|
Creation, retrieval, and deletion of Smart Links in the content tree and Databases have been added for v2 REST APIs. Creation, retrieval, modification, and deletion of properties as well as retrieval of operations and ancestors is supported via these added APIs.
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.
Thank you to all the partners who participated in the RFC for this update.
The Get page by id and Get blog post by id endpoints now support an optional query parameter, include-favorited-by-current-user-status. If the value of this parameter is true, the response payload will contain a boolean field isFavoritedByCurrentUser. The value of this field is true when the page or blog post is favorited by the calling user, and false otherwise.
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.
The Forge confluence:globalPage 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.
This resolves https://ecosystem.atlassian.net/browse/FRGE-600
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.
What was the issue?
Before Dec, 2023, when a partner published a new app version for a paid connect app, the app upgrade flow ran for all installed apps, without checking for active licenses.
As a result, partners saw failed /installed events for app upgrades for the connect apps that were unsubscribed but not uninstalled from the customer instance.
Tickets related to the issue: JAC Ticket, ECOHELP Ticket
What did we change?
At the time, we fixed this bug by:
Introducing checks and allowing only apps with active licenses to be auto-upgraded to new version.
In case of inactive licenses, when the customer resubscribes to the app and license becomes active, the auto upgrade works as usual.
Why are we reverting the change?
This change stopped partners from pushing security fixes among other updates to the unlicensed paid connect apps. To solve this, we would be rolling back the changes. This would be done in a phased manner rolling back 20% each day, until March 23.
By March 23, 2024, changes will be rolled back from all the customer instances.
What’s the impact of the reversion?
Reverting the changes will mean the auto upgrades run smoothly for all the apps including the ones with inactive licenses. Unfortunately, this takes us to the previous state which led to partners receiving failed /installed events for unlicensed paid connect apps.
We’ve added a set of new query parameters to the v2 Get inline comment by id API endpoint and the Get footer comment by id API endpoint that allows for optional fetching of metadata properties related to the given inline or footer comment. These include:
include-version
include-versions
include-labels
include-operations
include-properties
By default, these metadata properties (besides version) will not be included in the response unless specified.
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.
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.
Rate this page: