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.
We’ve introduced the following improvements to the Installation page in the developer console:
You can now view the dates when your app was first installed, for all its current installations.
You can now view logs associated with particular installations of your app. This is handy for faster access and troubleshooting.
See View app installations for more details.
Following the preview release, we’re pleased to announce that the new experience of viewing app logs is now generally available. By default, you can now use the new experience when viewing app logs in the developer console.
You can contact support if you encounter issues when using the new experience of viewing logs.
We’ve introduced the following improvements to app logs in the developer console:
You can now search for app logs using trace id, invocation id, modules, and log messages.
When downloading app logs, you can now find trace id values in both .csv and .log formats.
See View app logs for more details.
Here is the recent update on this Changelog.
Following our announcement regarding the introduction of App name validations to Marketplace, we received numerous inquiries from partners seeking additional time and clarification on the validations. In response, we have decided to ease the transition by implementing the following measures:
To enhance partners' comprehension of the app name validations, we are introducing an API endpoint that will allow partners to input an app name and receive a list of errors/warnings associated with that name. Partners can utilize this API endpoint to verify both existing app names and potential new app names they may consider in the future. More details on this API endpoint will be provided in a separate Changelog.
The deadline of Aug 15, 2024 will not act as a strict barrier for existing app names post-validation. We will be converting error messages to warnings for the following 30 days, ensuring that partner have sufficient time to address these violations and enhance the branding of their apps by September 15th, 2024.During this period, partners can view validation errors but will still be able to proceed with App version updates. However, net new apps submitted during this time will face a strict block and must adhere to the validations to progress towards review submission.
In order to enhance visibility and ensure that no apps are overlooked by partners, we will compile a list of apps with corresponding validation failures and generate tickets to notify partners of any branding violations detected and the operations team will reach out to you.
We fixed a timeout issue with the Basic Fetch API that occurred when a port was specified in the URL for the Forge Node.js runtime.
The fix will be applied once you re-deploy your app.
The list of supported ports has not changed (see https://developer.atlassian.com/platform/forge/runtime-reference/#https-only for details). Requests containing unsupported ports will result in an error response.
Upgrade to Bitbucket Data Center 9.0 to get many advantageous features, security enhancements, and API updates. This release also includes an upgrade to Atlassian Data Center Platform 7, which improves the quality of our response to security vulnerabilities with reduced disruption and changes for Marketplace apps.
Check out the whole bucket of updates in Bitbucket 9.0 release notes.
The createFrame helper function simplifies the communication between the UI Kit and Frame components. It enables the creation of custom Frame components with support for passing custom properties from UI Kit to Frame component resources as simple React component properties.
For more information about how to use the createFrame helper function, see here.
Confluence admins will be getting the ability to rename space keys. This EAP is to allow for early access and testing of 3rd party apps as well as any other interested parties.
The ability to change a Space key has garnered significant interest from numerous customers. Customers frequently request the capability to rename space keys due to organizational changes such as modifications in team or project names, acquisitions by other companies, organizational restructuring, or alterations in user names. Furthermore, unchangeable space keys creates obstacles when attempting to migrate spaces between Confluence instances with identical space keys.
This functionality addresses one of the most requested features in Confluence: allowing users to rename space keys.
To address this, we created the concept of Space Aliases. When you go to Space Settings, Space details, and Edit Space Details, you will see the “Space key:” field is editable. Note that, like the original space keys, these space aliases need to be unique across all spaces.
In places where you see space keys, you will see the new alias, and the alias can be used anyplace a space key currently can be used.
For developers, we kindly request that you refrain from scanning URLs to parse space keys. If this is currently being done, we strongly recommend transitioning to AP.context.getContext() or utilizing our V2 Space API to obtain the correct space key from its response.
Since the alias field is subject to change, it is recommended to avoid using aliases to store your application data. Instead, opt for using the Space ID whenever feasible. We want to ensure app developers have access to this change early so they can identify any issues this causes to their apps. For additional context about this EAP, please refer to our RFC-54 Introducing Space Alias in the Confluence URL.
By signing up for this Early Access Program (“EAP”), you acknowledge the Atlassian Privacy Policy and that:
Early access to Space Aliases is governed by the Atlassian Customer Agreement (“ACA”). This feature is considered a “Free or Beta Product”, as set forth in Section 17 of the ACA and is subject to applicable terms, conditions, and disclaimers.
Early access to updated Space APIs is governed by the Atlassian Developer Terms. These APIs are considered “Early Access Materials”, as set forth in Section 10 of the Atlassian Developer Terms and are subject to applicable terms, conditions, and disclaimers.
The documentation for this EAP is available at https://forms.gle/G6yZxWARL366oQna8.
Up until now, a card’s idShort field value would be restored to its previous value when the card is moved to a board it has previously been on.
Starting Aug 1, 2024 this will no longer be the case. idShort will always receive a new sequence ID on the destination board. This will have no impact on existing idShort values, or on idShort values on cards moved within a single board.
Ensure your app does not store references to idShort values persistently - they may be invalidated due to moves across boards.
In general, we advise against usage of idShort in favor of using the card’s id since idShort values might get invalidated.
We are excited to announce that Connect apps can continue using dynamic webhooks after adopting Forge capabilities. Apps can manage webhooks using the REST API with JWT-based authentication. The guide to dynamic webhooks for Connect apps provides detailed instructions and information about existing restrictions to 100 webhooks and a 30-day expiration period.
This feature is enabled only for Connect apps adapting Forge capabilities. For Forge apps, we highly recommend relying on product events.
Developers need to ensure that their webhooks are registered correctly and refresh any expired webhooks.
Midway through this quarter, we’ll be adding new Data Center app scanners to our suite of scanners (Ecoscanner) that scans Data Center apps listed on the Marketplace.
Here is what we’ll be scanning for:
Use of hardcoded secrets in Marketplace Data Center apps
Potential malware in Marketplace Data Center apps
To expand on this, the new DC app scanners will include:
Secret scanner: The new secret scanner will look for any hard-coded secrets in DC apps that could potentially pose a security risk if exposed. We engineered the scanner to detect secrets and manage potential security risks, ensuring that customer data remains protected from unauthorized access.
Malware scanner: Atlassian has implemented a robust malware scanning system for all Data Center applications in the Marketplace. This scan aims to identify and mitigate potential malware threats, thereby enhancing the security and integrity of our DC applications.
If a risk is detected: Atlassian will alert the app developer so they may investigate. If there is a critical risk, we recommend that Marketplace Partners notify customers.
We won’t begin issuing these new tickets to partners at this time; this is a preliminary announcement and an opportunity for partners to prepare. Atlassian plans on issuing tickets after August 15th 2024 via the AMS Jira project.
We are committed to working collaboratively with partners to continue improving the security of our Marketplace and fostering trust with our customers.
Partners with Partner Portal access can view the announcement in the Partner Portal blog.
On August 22, 2024, the functionality of /wiki/rest/api/user/bulk will change. The 'limit' parameter will no longer be functional for GET /wiki/rest/api/user/bulk operation; rather, the number of accountIds passed in will reflect the dictate the number of results returned. If your code sends the limit parameter, the API will ignore it.
Also, due to request header size limits, a maximum of 100 accountIds may be specified in a request. If you specify more than 100, only the first 100 will be returned. The documentation has been updated to reflect the limit of 100. It had previously stated 200, which was incorrect.
More details can be found here.
We are pleased to inform all Atlassian Marketplace partners that the hard-set limit for individual artifacts has been raised to 250 MB from 150 MB. This modification aims to facilitate a better uploading experience and effectively support larger file sizes.
We're introducing two new OAuth scopes, read:app-data:jira and write:app-data:jira for the following REST endpoints:
These new scopes are 100% optional now, and not using them won't break your app. However, we recommend adding them to your app's scope list at some point because we'll eventually make them mandatory.
We’ve extended the functionality of List users in a workspace API to support filtering the response by user’s email address. You can retrieve account IDs from the list of email addresses.
For more information, see the documentation.
Rate this page: