Last updated Jul 15, 2024

Atlassian developer changelog

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.

15 July 2024

Deprecation Notice ID's in the REST API for Assets in Jira Service Management cloud will be transitioning from numeric to UUID

REST API - JSM Cloud
REST API - CMDB/Assets

"id" fields in the various entities of the REST API for Assets in Jira Service Management cloud are of type string. Despite being a string, many of these contain a numeric value (for example "1245"). Please note that after the 30th of September 2024 some Asset entities will begin to be assigned a UUID value (for example "11ace219-a427-405c-bbb5-61d4f958e3fa") instead of a purely numeric one. If you have already treating these values as strings as per the API specification then you will not be effected by this change. If you have been assuming a numeric value within "id" fields, please make the appropriate adjustments to accomodate UUID’s before 30th of September 2024.

Note: despite all Asset entities being assigned a new UUID for the "id" field, the numeric values will continue to work as they do today when querying existing data via the publicly documented REST API’s. There is no need to update any id’s you might have previously stored in order to query particular data. This will be a backwards compatible change.

More details

If you have already treating these values as strings as per the API specification then you will not be effected by this change. If you have been assuming a numeric value within "id" fields, please make the appropriate adjustments to accomodate UUID’s before 30th of September 2024. Id’s on existing entities will continue to be queryable via their numeric id to maintain backwards compatibility.

12 July 2024

Announcement Blocking application access to frontend Forms APIs

REST API - Forms

On or after 2 August 2024, we’ll be discontinuing and blocking app access to our frontend Forms (previously ProForma) APIs in Jira Service Management Cloud.

To ensure uninterrupted service, we recommend transitioning any custom scripts and/or webhook Jira Automation rules that rely on API_TOKEN to access Forms to the Forms REST API. This will allow you to continue accessing this data, as well as maintaining long-term compatibility and support.

Announcement Forge apps utilising the Connect `lifecycle` module will move to distinct secrets

Forge - Jira Software Cloud (excludes JSW REST APIs)
Forge - Confluence Cloud (excludes Confluence REST APIs)

On Jul 30, 2024, we will begin rolling out a fix for Forge apps which declare the Connect lifecycle module to use a distinct shared secret that changes on major versions instead of a single shared secret like it is currently.

The history of why we are making this change and why we want to move to this secret model is outlined here. If you’ve followed the previous post, we expect no functional changes for app developers. Please ensure your apps are storing and maintaining secrets on a per-installation basis.

  1. On Jul 30, 2024, new Connect on Forge app installations, major version upgrades, and Connect to Forge migrations will start receiving distinct shared secrets.

  2. After Aug 7, 2024, we will be rotating the secrets of existing Connect on Forge app installations to move them to distinct shared secrets. A new installation payload containing this secret will be shared.

These changes will be rolled out on a per-tenant basis.

Fixed Additional Fields and Filters for Licenses and Transactions Reporting APIs

Marketplace Platform

Marketplace team has made a few updates to the licenses and transactions reporting APIs in terms of additional fields and filters.

  • Filter for manual invoices: During specific scenarios such as apps for enterprise parent licenses, invoices are manually generated. These invoices are then incorporated into the transactions report. To aid partners in effortlessly identifying and filtering out manually created invoices from their transaction history, we are introducing a new query parameter.

    • includeManualInvoice can be passed as a parameter while requesting for transactions with possible values as true or false. By default, the value will be set as false if not specified.

    • For more on how to use this parameter, partners can read the documentation here

  • Field for differentiating Atlassian and Non-Atlassian licenses: The license report from Marketplace includes licenses from various customer types. To assist partners in distinguishing between Atlassian-owned and non Atlassian owned licenses, a new field has been incorporated into the license response.

    • licenseSourceType in the licenses response will differentiate customers based on their domain and will have values Atlassian and Non-Atlassian

    • For more on how to use this parameter, partners can read the documentation here

  • Unique identifier for line items in transactions: The transactions report lacks unique IDs at the line item level, providing only an invoice ID. This limitation complicates the management, tracking, and updating of individual items within an order, particularly when an invoice contains multiple line items from the same application, making it challenging to differentiate between these items. To mitigate this issue, we are introducing a unique identifier for each line item.

    • transactionLineItemId in the transactions response will provide a unique identifier for each line item in transactions report

    • For more on how to use this parameter, partners can read the documentation here

  • Exposure of transaction account ID: In CCP cloud subscriptions, we use a unique identifier for each transaction account within Atlassian’s ecosystem. To help partners track and group licenses belonging to a specific billing entity, our licenses report will now contain this unique identifier in the response.

    • transactionAccountId is the licenses response will provide the transaction account ID

    • For more on how to use this parameter, partners can read the documentation here

Additional Bug Fix

We recently identified an issue where the evaluationOpportunitySize and tier fields in our license report were inaccurately displaying null or unknown response values. This was due to a reliance on the parent period for retrieving values in these fields. We have successfully addressed this issue and have updated all historical records along with refreshing the lastUpdated field.

11 July 2024

Announcement Forge tunnel now uses Cloudflare instead of ngrok

Forge - Core Platform (excludes product REST APIs)

On Jul 8, 2024 we announced that we started migrating forge tunnel to Cloudflare from ngrok. As of today, all developers using forge tunnel on Forge CLI 10.1.0 have now been migrated to Cloudflare.

We strongly recommend that you upgrade to the latest CLI version (see Upgrading for more details). If you are using a firewall, you may notice new connections to Cloudflare's tunnel infrastructure. For forge tunnel to work, ensure these connections are allowed.

Older CLI versions will continue to use ngrok for forge tunnel (and, therefore, will still require an ngrok account). For more information, see Tunneling.

Announcement New APIs for Developer Space on Marketplace

Marketplace Platform

As mentioned on our previous update on the deprecation notice for Vendor detail APIs here, below is the list of replacement APIs that we are providing to partners. These APIs aim to unify access control management for team members across Marketplace and Developer console in the future.

The revamped APIs are:

Please go through the DAC documentation to understand them in further detail.

Currently, these APIs only cater to deployment and are in development. You can expect some minor changes in the coming months. They’re expected to go live by October 2024.

Announcement Data Residency for Connect Apps: Now Generally Available

Connect - Core Platform (excludes product REST APIs)

We are pleased to share that the customer experience for Connect data residency is now generally available. This is inclusive of the data residency UI in the admin hub, which offers admins a clear and easy way for admins to manage their data.

Learn more about data residency for Connect Apps.

As we share this announcement with customers, Atlassian has encouraged customers to explore data residency options for their apps. Please be aware that this may result in a slight uptick in customer support inquiries concerning data residency.

More details

Data residency for Connect apps is just one more way to make meeting a key customer trust requirement easier than ever. It enables Atlassian organization administrators to specify where subsets of their product data at rest are hosted.

To take advantage of data residency for your Connect-hosted app, you’ll need to store any in-scope data (data that’s in-scope for data residency) in Connect. Then, update:

  • Your manifest so Atlassian is aware of your data residency offering

  • Your Privacy & Security tab so that customers know about your app’s support for data residency

Added Dynamic modules are now compatible with Connect apps adopting Forge

Connect - Core Platform (excludes product REST APIs)
Connect - Jira Cloud Platform (excludes Jira REST APIs)
Connect - JSM Cloud (excludes JSM REST APIs)
Connect - Jira Software Cloud (excludes JSW REST APIs)
Connect - Confluence Cloud (excludes Confluence REST APIs)

Connect apps adopting Forge can now register, retrieve and delete new and existing dynamic modules.

For more information, refer to Incrementally adopting Forge from Connect.

10 July 2024

Deprecation Notice AQL in Assets for Jira Service Management cloud will no support matching ID's on Status attributes

REST API - JSM Cloud
REST API - CMDB/Assets

AQL in Assets for Jira Service Management cloud supports queries on Status attributes using the Name of the Status. For example Status = ACTIVE

An undocumented feature also allows the same query using the ID of the Status as opposed to its Name. For example Status = 1. However as all Status Names are guaranteed to be unique within Assets, there is no benefit to using the ID.

We will be removing this undocumented feature after the 30th of September 2024.

More details

If you are using Status ID’s in your AQL queries, please adjust these to use the Status Name instead before the 30th of September 2024.

Announcement Making interacting with and configuring macros easier in the Editor

Connect - Confluence Cloud (excludes Confluence REST APIs)
Forge - Confluence Cloud (excludes Confluence REST APIs)

Today, we are starting the gradual roll out of a new selection / configuration control for macros in the Editor that will make it easier to configure macros while editing in Confluence, starting with sites in the Developer Canary Program and a portion of users. No updates or work will be required by app makers.

To see this in action, check out More details below.

More details

Thanks to all who left feedback in the RFC!

Announcement Upcoming Branding & Naming Validations for the Atlassian Marketplace

Marketplace Platform

We are implementing new validation checks during app publish flows and version update flows to ensure compliance with our branding guidelines for app naming and logo usage. The new validations are designed to automatically flag violations when a partner is in the publish flow. Furthermore, our partners have raised concerns regarding trademark issues, specifically instances where app names are duplicated, leading to branding violations and confusion. Therefore, we want to reiterate this policy and implement essential checks to protect the branding of all Atlassian Marketplace partners and their apps.

Why are we doing it ?

  • Consistency: To maintain consistent and accurate branding across Atlassian Marketplace.

  • Compliance: To ensure all apps adhere to the Atlassian Marketplace guidelines, prevent the use of proprietary and reserved words, and maintain clarity and a level playing field for all partners.

  • Efficiency: To enhance app reviews for quicker processing and improve user experience.

Atlassian Guidelines:

Below are more resources that provide detailed information on Atlassian’s branding guidelines:

Validation rules being applied for app names

More details

What do partners need to do?

  1. Review your app names: Verify that your app names adhere to the Atlassian guidelines. Refer to the potential violations outlined above for your review.

  2. Update if needed: Should you find that any of your app names do not conform to the guidelines, kindly make the necessary adjustments before Aug 15, 2024.

  3. Prepare for Future Updates: After this release, only compliant app names will pass the validation check for new submissions or updates through UI as well as APIs. Ensure your app names meet the guidelines to avoid any disruptions in completing version/name updates.

When will this change take place?

The rollout of these changes will be phased:

  • Milestone 1: Validation checks for app names will be deployed by Aug 15, 2024. After this milestone, all app names will be subject to validation when publishing a new app, a new version, or just updating the name. Should the app name fail to comply with the updated validation checks, it will be flagged, and partners will not be able to proceed to the next step.

  • Milestone 2: We also plan to implement subsequent validations for app logos. We will update partners on this document as soon as we have more information on this proposed change.

Frequently asked questions

9 July 2024

Removed `app.connect.authentication: oauth2` has been retired

Connect - Core Platform (excludes product REST APIs)
Connect - Jira Cloud Platform (excludes Jira REST APIs)
Connect - JSM Cloud (excludes JSM REST APIs)
Connect - Jira Software Cloud (excludes JSW REST APIs)
Connect - Confluence Cloud (excludes Confluence REST APIs)
Forge - Core Platform (excludes product REST APIs)

Connect apps registered on Forge are no longer able to set `app.connect.authentication: oauth2` in their manifest. This caused client credentials to be sent in the installation hook that could be exchanged for an api.atlassian.com access token. Developers wishing to make requests to api.atlassian.com from their app server should use Forge Remote instead. If you were relying on this feature, we’re happy to answer questions you may have about migrating on the Developer Community forums.

Announcement Correction of Refunds in Marketplace Transaction Report

Marketplace Platform

We have identified an issue affecting the accuracy of refunds in the transactions reports on the marketplace portal. The issue stems from a manual error in the upstream process of creating credit memos, leading to an incorrect linkage of the marketplace-related credit line. Around 25 transactions with the reason code assigned as "deal registration" were incorrectly added, causing discrepancies in the reports for various partners.

Our team is taking action to remove these erroneous transactions. Once these transactions are eliminated, the refunds will no longer appear on your marketplace reports. Please be assured that these “deal registration” refunds will not result in any reduced payments for the affected partners. We appreciate your patience as we work to rectify this issue by 12-July-2024. If you have any questions or need further assistance, please contact our support team at ECO-HELP.

Announcement Bitbucket 8.19.6 and 8.9.17 releases available now

Bitbucket Data Center

The bug fix releases for Bitbucket Data Center 8.19.6 and Bitbucket Data Center and Server 8.9.17 are available now!

To see the issues resolved in these bug fix releases, go to:

Get the latest LTS bug fix release

Added Accelerated transfers now supported across App Migrations

App Migration Platform

Starting from CCMA 3.9.17 and JCMA 1.11.12, all App Migrations will use accelerated transfers if the new endpoints are reachable.

Depending on the global region in which the App Migrations are being executed, this new feature can translate to up to 5x faster data uploads.

To ensure maximum impact, customers are advised to review their firewall policies according to this page.

Rate this page: