This page includes release notes and updates for Compass app developers. Use this page to keep track of new features, upcoming changes and deprecation notices about the Compass developer platform and GraphQL API.
If you're new to building apps for Compass, check out Get started building Compass apps to begin your journey.
For updates about changes to the Forge platform, see the Forge changelog in the Forge documentation.
You may also be interested in the What's New blog for Atlassian Cloud where we announce new product features and other major changes affecting all users of Compass.
We’re launching the new Forge Roadmap, updated every hour with the latest insights from our internal Jira Product Discovery. Developers and partners can use this roadmap to stay informed about upcoming features and changes. If you have feedback, share it in our community thread.
In the latest version of @forge/react (version 10.5.0), we are releasing a new set of UI Kit components alongside a few changes to existing components.
We are releasing the following new UI Kit components into Preview:
List
CheckboxGroup
Calendar
TimePicker
InlineEdit
Popup
EmptyState
For existing components, the following changes are being made:
Tag component now includes href prop
Icon component now includes primaryColor and secondaryColor props
For more information on the capability of these components, please find the corresponding component documentation
To update your UI Kit app to the latest version, in the terminal of your project directory, run the following command:
npm install --save @forge/react@latest
The upper limit of for Data security policy events has been increased to 200,000 objects, from the previous limit of 50,000 objects.
How does the upper limit work
This means that if a customer activates or updates a data security policy that affects more than 200,000 objects, you will receive the first 200k objects in the events and the rest would be omitted.
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.
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. App developers can subscribe to these events, we encourage you to read the Developer guide.
Forge functions can now interact with remote backends utilising Forge Remote. 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.
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.
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.
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.
The CompassScorecard field appliedToComponentStats is being deprecated in favor of scorecardScoreStatisticsHistories and criteriaScoreStatisticsHistories which provide historical statistics for scorecard scores and individual scorecard criteria scores. appliedToComponentStats will be removed on May 1, 2024.
This deprecation is necessary as we move to historical score statistics (scorecardScoreStatisticsHistories & criteriaScoreStatisticsHistories) for scorecards.
The new scorecardScoreStatisticsHistories and criteriaScoreStatisticsHistories fields are available now on CompassScorecard. The appliedToComponentStats field will be removed on May 1, 2024.
The legacy appliedToComponentStats field contains the most recent snapshot of scorecard and criteria score statistics. The same data can be reconstructed using statistics histories, where the last statistic returned for each Histories field is the most recent.
For scorecard score statistics, use scorecardScoreStatisticsHistories. Each node in the connection (type CompassScorecardScoreStatisticsHistory) contains an array of CompassScorecardScoreStatistic’s, which hold component counts for a scoreStatus. The previously hardcoded statuses can be filtered out by matching on scoreStatus == "PASSING", "FAILING", or “NEEDS_ATTENTION".
For criteria score statistics, use criteriaScoreStatisticsHistories. Each node in the connection (type CompassScorecardCriteriaScoreStatisticsHistory) contains an array of CompassScorecardCriterionScoreStatistic’s, which hold the component counts for a scoreStatusStatistic. The previously hardcoded statuses can be filtered out by matching on scoreStatusStatistic == "PASSING", "FAILING", or “ERROR".
Test your updates to make sure the same functionality is maintained from appliedToComponentStats.
Once you have confirmed that your changes work as expected, remove any references to the deprecated field.
There are no known issues with the migration process. However, if you encounter any issues during the migration, please consult the Support section below.
If you need help with the migration or have any questions, please visit the Compass Announcement category in CDAC or chat with our support engineers by clicking the “Give feedback” button in the top nav bar on your Compass site.
As we receive questions from developers and partners about the deprecation, we will update this section with answers to common questions. Please refer to the Support
You can now use Forge UI Kit 2 to build the user interface of your apps across all listed Compass modules and Jira Service Management (JSM) modules.
For more information on using UI Kit 2 components to design and build apps, see the UI Kit 2 components documentation.
Selecting a link to an external resource immediately takes you there without showing a warning-style confirmation message.
The individual criteria mutations (createScorecardCriterias, updateScorecardCriterias and deleteScorecardCriterias) are being deprecated and replaced with an expanded updateScorecard mutation which supports creating, updating and deleting criteria when updating a scorecard. The individual criteria mutations will be removed from the API on Aug 1, 2023.
This deprecation is necessary to improve scalability and enable future scorecard enhancements.
The three individual criteria mutations, createScorecardCriterias, updateScorecardCriterias, and deleteScorecardCriterias are being deprecated. Their functionality is now available as part of the updateScorecard mutation as createCriteria, updateCriteria, and deleteCriteria fields on UpdateCompassScorecardInput.
The following GraphQL types will be affected by this change:
CreateCompassScorecardCriteriasInput
UpdateCompassScorecardCriteriasInput
DeleteCompassScorecardCriteriasInput
UpdateCompassScorecardInput
The new createCriteria, updateCriteria, and deleteCriteria fields are available now on UpdateCompassScorecardInput. The createScorecardCriterias, updateScorecardCriterias, and deleteScorecardCriterias mutations, and their associated input types will be removed from the API on Aug 1, 2023.
To migrate from the individual criteria mutations to the consolidated scorecard update mutation, follow these steps:
Update your createScorecardCriterias GraphQL mutations to use the updateScorecard mutation instead by populating the createCriteria field on the UpdateCompassScorecardInput with the same CreateCompassScorecardCriteriaInput currently used.
Update your updateScorecardCriterias GraphQL mutations to use the updateScorecard mutation instead by populating the updateCriteria field on the UpdateCompassScorecardInput with the same UpdateCompassScorecardCriteriaInput currently used.
Update your deleteScorecardCriterias GraphQL mutations to use the updateScorecard mutation instead by populating the deleteCriteria field on the UpdateCompassScorecardInput with the same DeleteCompassScorecardCriteriaInput currently used.
Note that criteria validations are run against the entire set of criteria when using the scorecardUpdate mutation. This means creating, updating, and deleting criteria must be combined into a single scorecardUpdate mutation call, or they may be rejected for failing validation.
Test your updated scorecardUpdate mutations with different combinations of the criteria inputs to ensure they each function as expected.
Once you have confirmed that your mutations work as expected, remove any references to the deprecated mutations.
There are no known issues with the migration process. However, if you encounter any issues during the migration, please consult the Support section below.
If you need help with the migration or have any questions, please visit the Compass Announcement category in CDAC or chat with our support engineers by clicking the “Give feedback” button in the top nav bar on your Compass site.
As we receive questions from developers and partners about the deprecation, we will update this section with answers to common questions. Please refer to the Support section above if you have questions not addressed here.
In order to make Compass scorecard support multiple component types, we added a componentTypeIds field to our scorecard APIs. We are deprecating componentType and componentTypeId fields, and replace them with the new componentTypeIds field in following types: CompassScorecard, CreateCompassScorecardInput, UpdateCompassScorecardInput.
As we continue to grow and expand our component types, we need to provide greater flexibility in how our customers apply scorecards to their components. Currently, a scorecard can only be applied to one component type, with a limit of 50 scorecards. Customers have requested the ability to apply the same scorecard to multiple component types, reducing the burden of creating multiple identical scorecards to track components with different types.
To address this need and better support our growing component types, we are deprecating the componentType and componentTypeId fields in scorecard GraphQL APIs and replacing them with a new componentTypeIds field. The componentTypeIds field allows you to assign multiple component types to a single scorecard.
The following GraphQL types will be affected by this change:
CompassScorecard
CreateCompassScorecardInput
UpdateCompassScorecardInput
The new componentTypeIds field is now available. The componentType and componentTypeId fields will be removed from the API on Oct 20, 2023 (until then, they will continue to be supported).
To migrate to the new componentTypeIds field, follow these steps:
Update your GraphQL queries and mutations for Compass Scorecard to use the componentTypeIds field instead of the componentType and componentTypeId fields. The componentTypeIds field expects an array of component type IDs.
Test your updated queries and mutations to ensure they work as expected with the new field.
Once you have confirmed that your queries and mutations work with the new field, remove any references to the deprecated componentType and componentTypeId fields from your code.
There are no known issues with the migration process. However, if you encounter any issues during the migration, please consult the Support section below.
If you need help with the migration or have any questions, please visit the Compass Announcement category in CDAC or chat with our support engineers by clicking the “Give feedback” button in the top nav bar on your Compass site.
As we receive questions from developers and partners about the deprecation, we will update this section with answers to common questions. Please refer to the Support section above if you have any questions that are not addressed here.
The src property of the UI Kit Image component will go through a permission check in the near future.
A specific date cannot be given for this change since it will depend on when each product adopts it.
If the Image component is using an URL as its source, follow this External Permissions - Image guide to add permissions for that URL.
data:image URIs will be allowed by default as the Image source.
If the corresponding permission is not given to the source of the image when specified with a URL, then the image will not load.
To help you debug your Forge apps, the developer console now lets you group your metrics by app function. Each chart now has a Group by dropdown menu, with the option to select Function. For more information, see Monitor your apps.
We’ve introduced a new metric to the developer console - invocation time! You can now see the invocation time for your Forge apps by selecting Metrics in the left menu and scrolling to the new invocation time chart, which shows the speed of your function invocations, separated into time buckets.
You can also select the Go to detailed view link at the bottom of the chart, to get a more in-depth view of invocation time, including the P50, P90, and P95 for individual functions.
Rate this page: