Last updated Apr 9, 2024

Changelog

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.

9 April 2024

Announcement Two-step verification login for Data Center

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.

More details

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.

27 March 2024

Announcement Preparing for Jira 10.0 (EAP 02)

Jira Software 10.0 EAP 02 is now available

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.

More details

This EAP release is not for production or demonstration use.

Known issues

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

Coming up next

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)

Early Access Preparing for Jira Software 10.0 (EAP 02)

Jira Software Data Center is migrated and fully exposes RESTv2

For more information, check out the RESTv2 migration guide.

Early Access Preparing for Jira Software 10.0 (EAP 02)

Centralized dependency management

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.

More details

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.

Using artifacts for version management

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>

Adopting centralized BOMs in App Development

To adopt centralised BOMs, follow these steps:

  1. Remove the jira-project dependency management import.

  2. Add jira-api-bom as a dependency with scope import.

  3. Consider adding jira-deprecated-api-bom if needed, but note that these dependencies are marked as deprecated and will be removed in future versions.

  4. Remove redundant dependency management sections from your poms (for artefacts covered by the bom)

  5. 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.

  6. 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

  7. 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.

Early Access Preparing for Jira Software 10.0 (EAP 02)

Removal of dependencies

We’re planning to remove access to a number of dependencies from Jira Software 10.0, which are currently accessible in Jira 9.x.

More details

Dependency

Java packages

nekohtml:nekohtml

org.cyberneko.html
org.cyberneko.html.*

commons-validator:commons-validator

org.apache.commons.validator
org.apache.commons.validator.*

com.atlassian.scala.plugins:scala-2.11-provider-plugin

scala.*

com.atlassian.scala.plugins:scala-2.10-provider-plugin

scala.*

com.atlassian.scala.plugins:jackson-module-scala-2.10-provider-plugin

com.fasterxml.jackson.module.scala2_10

io.atlassian.fugue:fugue-scala

io.atlassian.fugue.converters

commons-daemon:commons-daemon

org.apache.commons.daemon.*

org.apache.tomcat:tomcat-coyote

org.apache.coyote.*

commons-el:commons-el

org.apache.commons.el.*

org.apache.tomcat:tomcat-jasper

org.apache.jasper.*

org.apache.tomcat:tomcat-juli

org.apache.juli
org.apache.juli.logging

org.apache.tomcat:*

org.apache.tomcat
org.apache.catalina

org.apache.tika:tika-core

org.apache.tika:tika-*

 

org.apache.tika
org.apache.tika.*

org.apache.xmlgraphics:batik-transcoder

org.apache.xmlgraphics:batik-codec

org.apache.xmlgraphics:batik-js

org.apache.xmlgraphics:batik-svggen

org.apache.xmlgraphics:fop

org.apache.batik
org.apache.batik.*

com.querydsl:querydsl-core

com.querydsl:querydsl-sql

com.mysema.commons.lang
com.querydsl.core
com.querydsl.core.*

commons-configuration:commons-configuration

org.apache.commons.configuration
org.apache.commons.configuration.beanutils

org.apache.commons:commons-collections4

org.apache.commons.collections4

com.thoughtworks.xstream:xstream

com.thoughtworks.xstream
com.thoughtworks.xstream.*

org.apache.commons:commons-dbcp2

org.apache.commons.dbcp2
org.apache.commons.dbcp2.cpdsadapter
org.apache.commons.dbcp2.datasources
org.apache.commons.dbcp2.managed

com.sun.syndication:com.springsource.com.sun.syndication

com.sun.syndication.feed.*
com.sun.syndication.io.*

rome:rome

com.sun.syndication.feed.*
com.sun.syndication.io.*

commons-discovery:commons-discovery

org.apache.commons.discover.jdk
org.apache.commons.discovery.*

commons-jexl:commons-jexl

org.apache.commons.jexl.*

commons-jrcs:commons-jrcs

org.apache.commons.jrcs.*

com.github.rholder:guava-retrying

com.github.rholder.retry.*

org.dom4j:dom4j

org.dom4j.*

opensymphony:sitemesh

com.opensymphony.module.*
com.opensymphony.sitemesh.*

org.jdom:jdom

org.jdom.*

commons-pool:commons-pool

org.apache.commons.pool.*

org.tuckey:urlrewritefilter

org.tuckey.web.filters.urlrewrite.*

org.springframework.security:spring-security-core

org.springframework.security.*

com.atlassian.p4package:atlassian-p4package

com.perforce.api

commons-beanutils:commons-beanutils

org.apache.commons.beanutils
org.apache.commons.beanutils.*

org.apache.commons:comons-compress

org.apache.commons.compress
org.apache.commons.compress.*

com.sun:jai_core

com.sun.media.jai.*
javax.media.jai
javax.media.jai.*

com.sun:jai_codec

com.sun.media.jai.*

wsdl4j:wsdl4j

com.ibm.wsdl
com.ibm.wsdl.*
javax.wsdl
javax.wsdl.*

Early Access Preparing for Jira Software 10.0 (EAP 02)

Breaking changes to the API

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.

More details

Change

Instructions

Deprecated com.atlassian.jira.issue.table.IssueTable provided by jira-api removed

Use com.atlassian.jira.issue.table.IssueTable provided by jira-issue-nav-plugin.

com.atlassian.jira.rest.Dates.DateAdapter removed

com.atlassian.jira.rest.Dates.DateTimeAdapter removed

For marshalling and unmarshalling use Jackson-friendly Serializers/Deserializers:

@JsonSerialize(using = Dates.DateSerializer.class)
@JsonDeserialize(using = Dates.DateDeserializer.class)

 

com.atlassian.jira:jira-func-tests-legacy is removed.

Migrate your code from BaseJIRAWebTest (Junit3) to FuncTestCase (Junit 4+). This module was deprecated since Jira 7.

doHealthCheck request parameter is removed from rest/api/2/serverInfo endpoint and healthChecks field in the response is removed.

Use jira-healthcheck-plugin instead

rest/api/1.0/endpoint is removed.

No alternative.

com.atlassian.jira.rest.v2.issue.project.ProjectRoleBean and com.atlassian.jira.rest.v2.issue.project.RoleActorBean are removed

Use com.atlassian.jira.rest.api.project.ProjectRoleBean and com.atlassian.jira.rest.api.project.RoleActorBean instead

com.atlassian.jira.rest.v1.model.ValueCollection is removed.

No alternative.

com.atlassian.jira.testkit.client.restclient.Response class of jira-testkit-client has been deprecated

com.atlassian.jira.testkit.client.RestApiClient.toResponse(...) accepts RestCall functional interface

Use com.atlassian.jira.testkit.client.restclient.ParsedResponse

 

Use new RestCall interface or lambda in place of Method interface

Jira table column update for Oracle and Mysql.

No actions required, schema would be migrated on restart.

Impacted tables include: changegroup jiraissue jiraaction

com.atlassian.jira.avatar.AvatarManager
#getAvatarBaseDirectory

Use AvatarManager#readAvatarData() to access avatar data directly.

21 March 2024

Announcement Preparing for Jira Software 9.15 and Jira Service Management 5.15

Restrict file extensions that can be uploaded to Jira

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

More details

How to restrict file extensions?

To configure file formats that you’d like to allow or block in your instance:

  1. In the upper-right corner of the screen, select Administration > System.

  2. 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.

  3. Select Edit settings. The Edit attachment settings dialog will open.

  4. For Restrict file extensions, select Blocklist or Allowlist. If you’d like to allow all file extensions for uploading, select Off.

    1. The blocklist will contain file extensions blocked from uploading. All other file extensions will be allowed.

    2. The allowlist will contain file extensions allowed for uploading. All other file formats will be blocked.

  5. 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.

  6. If needed, select Include files without extensions. Files without any extension will be either blocked or allowed, based on the previous setting.

  7. 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.

Announcement Preparing for Jira Software 9.15 and Jira Service Management 5.15

Tightening access with a websudo allowlist

To add an extra layer of security to websudo operations, you can configure and enable your own IP address/subnet allowlist for Jira. This means that certain superuser operations can only be performed from pre-approved IP addresses. This feature is deactivated by default.

More details

Here’s some more information about how to configure and activate the websudo allowlist.

Before you begin

Before enabling your websudo allowlist, your system must be set up to run it correctly. Read and understand the following sections on best practice and other useful info to avoid running into any problems.

  • Make sure you can’t lock yourself out by including more than one single IP address in your allowlist.

  • Configure your allowlist based on VPN settings.

  • For long allowlists, we recommend using CIDR notation, and/or patterns with wildcards (for IPV4 addresses only — for example, 103.12.*.*).

  • Keep your allowlist restricted to reduce security concerns. For example, including *.*.*.* is equivalent to switching off the allowlist restrictions altogether.

  • Take a backup of your config file. You will need this if you lock yourself out.

Other useful info

  • The websudo allowlist is a comma-separated list.

  • Any server or service responsible for handling connections from the internet should include the client's IP address as a header in the HTTP request. This header will then be forwarded to internal servers/nodes for processing. By default, this feature uses the X-Forwarded-For header as the source of the client's IP address. However, you can change the name of this header by modifying the server.tomcat.remoteip.remote-ip-header configuration property in the jira-config.properties file.

  • If any strings in the allowlist contain an error, such as a typo, or an invalid character, that configuration portion will be omitted from the service configuration. Although unlikely, it is possible that no IP addresses would be allowed for this feature, resulting in no one being able to use websudo. In such cases, you must change the specified properties to provide correct values before enabling the allowlist.

Configure your websudo allowlist

Your websudo allowlist is configurable as comma-separated lists of IP addresses and CIDR addresses within your Jira configuration file (jira-config.properties). Follow the steps below to configure your allowlist.

  1. Locate your jira-config.properties file and take a backup of it.

  2. Open your live jira-config.properties file in your preferred text editor.

  3. If you would like to add IP addresses, add the websudo.allowlist.ip property to your file, and add your comma-separated list of IP addresses.
    For example:

    1 websudo.allowlist.ip=172.29.143.247,2001:0db8:85a3:0000:0000:8a2e:0370:7330
  4. If you would like to add IP address subnets, add the websudo.allowlist.cidr property to your file, and add your comma-separated list of CIDR addresses.
    For example:

    1 websudo.allowlist.cidr=8.8.8.1/24,0:0:0:1::/64
  5. Check for any errors to ensure your lists won’t be omitted from the service configuration.
    Hint: look for the error text: Exception while parsing IP/CIDR Pattern {}. Ignoring part {}

  6. Save your configuration file.

Activate the websudo allowlist service

After you've configured your allowlist and you’re certain your address details are included in the allowlist, you can enable it. Follow the steps below.

  1. Open your live jira-config.properties file in your preferred text editor.

  2. Search for websudo.allowlist.enabled.

  3. If the string is missing, add it to your file.

  4. Change the string’s value to true.

  5. Save and close your configuration file.

  6. Restart Jira for the changes to take effect.

Deactivate the websudo allowlist service

If you wish to stop using the websudo allowlist service, you can do so if you’re using any of the addresses listed in the allowlist. Follow the steps below.

  1. Open your live jira-config.properties file in your preferred text editor.

  2. Search for websudo.allowlist.enabled.

  3. Change the string’s value to false.

  4. Save and close the configuration file.

  5. Restart Jira for the changes to take effect.

Announcement Preparing for Jira Software 9.15 and Jira Service Management 5.15

Jira Software 9.15 and Jira Service Management 5.15 EAP 02 are now available

The second EAP for Jira Software 9.15 and Jira Service Management 5.15 is ready for testing. You can download the EAP from this page. If you’re using maven.atlassian.com, here are the versions: 9.15.0-m0003 for Jira Software and 5.15.0-m0003 for Jira Service Management.

If you want to share your feedback, just leave a reply in the Atlassian Developer Community thread.

Announcement Preparing for Jira Software 9.15 and Jira Service Management 5.15

Confluence Page Viewer replaces the Confluence Page Gadget

In this release, we’re replacing the old and popular Confluence Page Gadget with the new Confluence Page Viewer dashboard gadget. Just like with the old one, you can use Confluence Page Viewer to embed a page from a linked Confluence Data Center site on your Jira dashboard. The new gadget is built on top of a modern and secure technology stack and comes with several UI improvements.

You can select a page to embed by the space name and page title or by a specific page ID.

More details

Before you begin

Before you start using the Confluence Page Viewer gadget, make sure that:

  • you have at least one active application link to a Confluence Data Center site (for more information, go to Link to other applications)

  • you’re logged in to your Confluence Data Center site in the same browser session you’re using to add the gadget and view embedded content

Adding the gadget to your dashboard

To add the Confluence Page Viewer gadget to your dashboard:

  1. Go to the dashboard by selecting the Dashboards link in the Jira header.

  2. If you don't already have a dashboard, select Manage Dashboards from the menu, then select Create new dashboard.

  3. Once your dashboard is created, select Add Gadget.

  4. In the the gadget wizard, search for Confluence Page Viewer and then, select Add gadget.

7 March 2024

Announcement Preparing for Jira Software 9.15 and Jira Service Management 5.15

Improvements to modal dialogs in Assets

We improved the user experience of modal dialogs and addressed several accessibility issues by upgrading the Atlassian User Interface (AUI) dialog from AUI Dialog1 to AUI Dialog2 in Assets.

Announcement Preparing for Jira Software 9.15 and Jira Service Management 5.15

Transition from http-builder library to native Groovy GET and POST

We are planning to remove the http-library in Jira Service Management 6.0 because it is not being actively maintained. If you are using this library in Groovy scripts, we recommend that you switch to the native Groovy GET and POST methods.

Announcement Preparing for Jira Software 9.15 and Jira Service Management 5.15

Archive unused Assets objects

We’re working to introduce the ability to archive to assets you no longer need. This helps you declutter your instance and improve the performance of object searches. Previously, you had to permanently delete objects when your available index memory was low to make room for new objects. Now, you can archive objects instead. If you accidentally archive any objects, you can always restore them.

More details

To archive an object:

  1. Log in as an Assets Manager, Assets Administrator, or a Jira admin.

  2. Navigate to an object and then from the More options menu, select Archive.

If you’ve unintentionally archive an object and want to restore it:

  1. From the top navigation bar, select Assets then Archived objects.

  2. Use the filters to search for the object and select Restore.

Announcement Preparing for Jira Software 9.15 and Jira Service Management 5.15

Encrypted credentials will be re-encrypted on upgrade

We streamlined the way in which credentials are encrypted across Jira Service Management. When you upgrade, saved credentials (such as email channels, Opsgenie, and Confluence Cloud API keys) will be re-encrypted using a new cipher library.

This change will not affect your upgrade process. In case you run into any issues, re-enter the credentials. This will re-encrypt the credentials before they are saved to the database.

Announcement Preparing for Jira Software 9.15 and Jira Service Management 5.15

Expected downtime due to database upgrade in Jira Software 10.0 and Jira Service Management 6.0

We’re planning to change the structure of MySQL and Oracle databases in Jira Software 10.0 and Jira Service Management 6.0 to enhance the accuracy of timestamps for operations, down to the millisecond (operations such as creating issues, updating comments, or changing statuses).

If you’re using a MySQL or Oracle database, you’ll notice an additional upgrade downtime as some columns from the jiraissue, jiraaction, and changegroup tables will be migrated during the upgrade. We expect this downtime to be less than 20 minutes if you have fewer than five million issues. Note that the downtime will be proportional to your database performance, size, and the row count in the jiraissue, jiraaction, and changegroup tables.

More details

To get an accurate estimate and plan your upgrade:

  1. Find the row counts by running the following commands in your database:

    1 2 3 SELECT COUNT(*) FROM jiraissue; SELECT COUNT(*) FROM jiraaction; SELECT COUNT(*) FROM changegroup;
  2. Use the following benchmark data provided for Amazon RDS db.m6g.8xlarge and estimate your downtime:

    • jiraissue table: approximately 26.527 seconds per million rows

    • jiraaction table: approximately 7.592 seconds per million rows

    • changegroup table: approximately 9.468 seconds per million rows

 For example, if you have 5 million, 8 million, and 80 million rows in the jiraissue, jiraaction, and changegroup tables respectively, you can expect a downtime of about 16.65 minutes.

Rate this page: