We've moved the communication about Jira Software Data Center and Jira Service Management Data Center releases and updates to this changelog. With this transition, we aim to provide partners and developers with a customizable feed of improvements and changes to our products.
You can continue using the Atlassian Developer community for discussion and support. Subscribe to the category to stay tuned!
If you're a Jira Data Center app developer, use this page to track upcoming changes, deprecation notices, new features, and feature updates on the Jira Data Center platform.
The first EAP for Jira Software 9.16 and Jira Service Management 5.16 is ready for testing. You can download the EAP from this page. If you’re using maven.atlassian.com, here are the versions: 9.16.0-m0001 for Jira Software and 5.16.0-m0001 for Jira Service Management.
If you want to share your feedback, just leave a reply in the Atlassian Developer Community thread.
You can now secure your Assets imports with the Jira allowlist. This way, you can make sure that your import configurations (such as Object Schema import, LDAP import) get data only from allowed external sources.
To start using this feature:
Make sure that the allowlist in Jira is configured.
Navigate to Jira administration, select Manage apps then Assets configuration.
In the Security section, select Yes for Use the Jira Allowlist to block import configuration URLs.
1: New setting to filter import configuration URLs
To reduce the computational load on your instance, your Workload report now contains additional filters, and is configured by default to show only agents with assigned issues. This will speed up the load time of Workload reports in large Jira Service Management instances and reduce timeouts. Whenever you need to view the workload of all agents, just modify the search filter.
1: New filter to view agents with workload
As we continue to strengthen the security of our products, we’ve made some changes to the Groovy scripts interface in Assets to reduce the risk of arbitrary code execution. From Jira Service Management 5.16, the Groovy script console, which lets you build and execute scripts on the fly, will no longer be available across Assets.
You can continue to use and run Groovy scripts, but you’ll need to store them in a common script directory (located within the shared home directory of Jira) and add the script path for use within workflow transitions and object schema automations. We’ve added a new read-only panel to help you easily verify script content before you use or run scripts. How to use Groovy scripts
This feature is on by default and the change impacts the following:
The console available in Administration (select Manage apps then Assets script console).
The console available in Workflows (conditions, validators, post functions).
The Automation tab in Assets schema configuration.
The Assets allowlist page will no longer be available. However, your existing automations that rely on the scripts you added to the allowlist before this upgrade won’t be affected. The new Groovy scripts page contains a read-only list of these allowlist files.
Any file paths you saved in Workflows will be added to the allowlist during the upgrade.
Any code you added to the console before the upgrade will be available in the read-only panel.
Introducing additions to the Assets archiving experience we released in 5.15. You can now restore archived objects easily from the Archived objects page and take advantage of the new Archive object action in Assets automations. More about archiving objects
What’s new?
Search for objects in the Archived objects page and:
use the new Archived by me filter to search for objects that you’ve archived
restore an archived object directly from this page (select an object and then from the Actions column, select More actions (…) and then Restore)
bulk restore objects (you can either select Restore all to restore all the filtered objects or select the desired objects and then select Restore selected)
Use the new Archive object action in Assets automations. Note the following:
For the action to run successfully, the rule needs to run as a user with manager permissions for the object type.
Each condition can contain only one Archive object action.
As attributes can’t be updated on archived objects, you can’t add an Attribute value action after an Archive object action.
As archived objects can’t be updated, any actions that trigger changes to archived objects will fail. For example, Groovy script or HTTP request actions that attempt to modify objects affected by the Archive object action.
1: New action to archive objects
If you’re already running your Jira Data Center instance in AWS, you can now securely store backups in Amazon S3 object storage.
The prototype version of the new login experience for Data Center is now available. Download this .jar file and test it against your apps to identify any potential conflicts.
This prototype is intended purely as a test to check how the new two-step verification experience affects your apps' functionality and determine if any changes are necessary. The scope, functionality, API, quality, look and feel, and security level of the prototype aren’t representative of the final solution.
The production version of two-step verification will be developed separately from the prototype version but the fundamental technical concept will remain unchanged.
This prototype is for testing purposes only. Don’t install it on production environments.
To install the app, follow https://confluence.atlassian.com/upm/installing-add-ons-273875715.html#InstallingMarketplaceapps-InstallaDataCenterorServerapp. In case the upload is disabled, check https://confluence.atlassian.com/jirakb/how-to-re-enable-plugin-upload-1364557898.html.
Watch this video guide for more information on the prototype and how to test it.
As part of our ongoing commitment to security, we’ll cease publishing development releases of Data Center product artifacts to the Atlassian Maven repository. Moving forward, only artifacts used in the Early Access Program (EAP) and final product releases will be available to maintain the highest level of security for our customers.
For an added layer of security, we’re bringing a new login experience supporting two-step verification in Confluence, Jira Software, and Jira Service Management Data Center.
We’re replacing the current product-specific login pages for Confluence, Jira Software, and Jira Service Management Data Center with a unified experience.
The new login process will support built-in two-step verification capability, using time-based one-time password (TOTP) as a second factor. It will be managed by the Atlassian SSO for Data Center app, which is currently bundled with the products but will transition into a system plugin.
This change stands as an integral component of our security hardening initiative. Our aim is to establish more robust authentication measures to mitigate the risk of unauthorized access to Atlassian Data Center product instances.
We recognize that this change may potentially disrupt some integrations reliant on the REST API or UI elements. It's in our mutual interest to ensure that customers using Marketplace apps for authentication encounter no interruptions.
In a few weeks, we’ll launch an Early Access Program (EAP) for the Proof of Concept (POC) version of the solution and annouce it in this changelog. We urge you to take advantage of this opportunity to test your apps integrations.
We’re happy to present the first Early Access Program (EAP) build of Jira Software 10.0. This build focuses primarily on exposing Jira with its internal REST subsystem migrated to RESTv2.
Currently, REST v2 impacts Jira Software Data Center only. Jira Service Management is also in the scope of RESTv2 and is now undergoing migration. It’ll be included in future EAPs.
For more detailed information, check out the following change log entries:
You can download the EAP from this page. If you’re using maven.atlassian.com, the version is 10.0.0-m0002.
If you want to share your feedback, just leave a reply in the Atlassian Developer Community thread.
This EAP release is not for production or demonstration use.
The following subsystems are known to be not functional in this release:
Jira Service Management
Advanced Roadmaps may be unstable and not functioning correctly
Jira Cloud Migration Assistant doesn’t load
The Manage Apps page shows apps out of date with MPAC
Overall stability issues across the system
Next milestones are coming soon through the EAP channel and will focus on:
Completing the migration to RESTv2 across all Atlassian apps
Removing deprecated dependencies
Removing deprecated code
Changing the Java language level to 17
Platform 7 (including removal of RESTv1)
For more information, check out the RESTv2 migration guide.
Centralized dependency management in Jira Software 10 introduces a set of Maven POM files known as a Bill of Materials (BOM), which list the dependencies available to third-party apps.
This system aims to streamline responding to security threats and enhance efficiency of developing for Jira by ensuring that dependencies are uniform and up-to-date. This approach minimizes runtime errors such as NoSuchMethodException and allows for quicker responses to security vulnerabilities within these dependencies.
There are multiple BOM files, each serving different functions:
jira-api-bom: This BOM is designed for external products. It offers a centralized location for managing the dependencies of external products, ensuring that they’re using the correct, up-to-date versions of dependencies.
jira-deprecated-api-bom: This BOM lists libraries that may undergo changes or be removed from the public Bill of Materials in future updates.
jira-internal-bom: This BOM is intended for internal products. It provides a centralized location for managing internal dependencies, ensuring consistency across all internal products.
jira-bundled-plugins-bom: This BOM manages the versions of apps bundled with Jira.
BOMs (Bill of Materials) are Maven modules of the pom packaging type, which are designed to facilitate the management of imported dependencies as detailed in the Maven documentation.
Each BOM contains dependency management sections rather than direct dependencies. To use a BOM, you should first include it as a dependency with the import scope. For example:
1
2
3
4
5
6
7
<dependency>
<groupId>com.atlassian.jira</groupId>
<artifactId>jira-api-bom</artifactId>
<version>${jira.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>Subsequently, other dependencies should be explicitly defined manually with the scope provided, omitting version specifications. The versions will be configured through the imported BOM artifacts. For example:
1
2
3
4
5
<dependency>
<groupId>com.atlassian.security</groupId>
<artifactId>atlassian-secure-utils</artifactId>
<scope>provided</scope>
</dependency>To adopt centralised BOMs, follow these steps:
Remove the jira-project dependency management import.
Add jira-api-bom as a dependency with scope import.
Consider adding jira-deprecated-api-bom if needed, but note that these dependencies are marked as deprecated and will be removed in future versions.
Remove redundant dependency management sections from your poms (for artefacts covered by the bom)
Since BOM does not define scope, if your dependency management section used to contain scope definition, you must now add it to the actual dependency declaration.
Conduct deep analysis of the dependency tree to ensure all dependencies are correctly managed, and no discrepancies exist between versions. All dependencies listed in the bom files
Ensure that dependencies, especially those in the provided scope, don't have a version field to allow the central pom to define it. This ensures consistency and prevents runtime issues.
We’re planning to remove access to a number of dependencies from Jira Software 10.0, which are currently accessible in Jira 9.x.
Dependency | Java packages |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
In the first Jira 10.0 EAP, you’ll see appropriate entries in api-deprecated-bom, although no changes to the configuration have been made. These changes will be effective in the subsequent EAPs.
Change | Instructions |
|---|---|
Deprecated | Use |
| For marshalling and unmarshalling use Jackson-friendly Serializers/Deserializers:
|
| Migrate your code from |
| Use |
| No alternative. |
| Use |
| No alternative. |
| Use
Use new |
Jira table column update for Oracle and Mysql. | No actions required, schema would be migrated on restart. Impacted tables include: |
| Use |
In Jira Software and Jira Service Management, admins can now restrict file formats uploaded through issues. By creating an allowlist or a blocklist of particular file extensions, you’ll protect both your Jira instance and your company’s infrastructure from potential malware uploaded in attachments.
This feature comes with a new plugin API that now can implement custom attachment validators. Find out more about the Attachment validator module
To configure file formats that you’d like to allow or block in your instance:
In the upper-right corner of the screen, select Administration > System.
In the sidebar, select Advanced > Attachments. You’ll find two groups of settings: General settings for global attachment configurations and Security settings for restricting file extensions.
Select Edit settings. The Edit attachment settings dialog will open.
For Restrict file extensions, select Blocklist or Allowlist. If you’d like to allow all file extensions for uploading, select Off.
The blocklist will contain file extensions blocked from uploading. All other file extensions will be allowed.
The allowlist will contain file extensions allowed for uploading. All other file formats will be blocked.
In the Specify file extensions field, enter file formats that you’d like to block or allow, based on the previous setting. Separate your file formats with a comma. For example: exe, dll, pdf.
If needed, select Include files without extensions. Files without any extension will be either blocked or allowed, based on the previous setting.
Select Save.
The new configuration will apply only to new files uploaded after you’ve set it. The files attached before you’ve set the configuration won’t be checked for their extensions.
Rate this page: