Rate this page:
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.
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.
To make it easier and safer to distribute your Forge app via the developer console, you can now generate new installation links. When you generate a new link, users with the previous link will no longer be able to install your app (however, they can still update to new versions). This gives you more control when distributing your app to specific audiences.
In the developer console, you can now edit the target value of your Forge app alert. Previously, the alert was set at a target value of 99%. Now you can choose from a number of values between 99% and 60%.
For more information, see Manage app alerts.
To quickly identify the current state of your Forge apps, the developer console now displays values, as well as charts, for each metric. For more information, see View app metrics.
To help you debug your Forge apps, the developer console now lets you group your metrics by app version. Each chart now has a Group by dropdown menu, with the option to select Version. For more information, see Monitor your apps.
In the developer console, you can now edit the title and description of your app alert, as well as view alert history. You can also see the metrics highlighted when value is below the threshold. For more information, see Manage app alerts.
To help you debug your Forge apps, the developer console now displays site-specific information about your app's invocation errors. Just select the invocation errors chart title, or select the More actions (⋯) menu on the chart and View details.
For more information, see Monitor your apps.
To help you monitor the performance of your Forge app, we’ve introduced alerts for when your app’s invocation success rate changes. If your app’s invocation success rate falls below 99%, we’ll send you an email. If you don’t want to receive these emails, you can mute and unmute the alert at any time.
EDIT, 17 Aug, 2022: This change was originally announced on August 15th, 2022. However the change was only made effective in production as of August 17th, 2022 (AEDT). Our apologies for any confusion caused.
To help you debug your Forge apps more easily, app logs are now available by default when a user installs your app on their site.
Previously log access was disabled by default. If you needed log access for your app on a user’s site, you had to ask the user to manually give you log access through Admin Hub.
Now log access is enabled by default. When a user installs your Forge app on their site, you will now have automatic access to logs for your app on their site.
Note, apps that are already installed will remain in their current state of log sharing, with log access disabled by default, but we are investigating how to change this.
Disabling access
Users can still manually disable or re-enable log access through Admin Hub. This will remove your access to the logs for your app on their site, including any historic logs that were generated when you previously had access.
To help you when handling logs for your Forge app, we have added new Logging guidelines for app developers. These guidelines outline some best practices to consider when handling logs and determining what data you should, and should not, be logging.