Preparing for Jira 8.16

This documentation is intended for Jira developers who want to ensure that their existing apps are compatible with Jira 8.16. 

Summary of changes

In this section we'll provide an overview of the changes we intend to make, so you can start thinking how it might impact your apps. Once they're ready, we'll indicate when a change has been implemented, and in which milestone. 

Fix for custom fields that don’t support default values

Status: IMPLEMENTED (RC-02)

In previous EAPs, we’ve introduced a bug that was a result of our changes to system fields. Because of this bug, you couldn’t configure custom fields that don’t support default values, which made them pretty much unusable. Instead of the links to configuration items, you’d see a message: “This custom fields doesn’t support default values”.

We’ve fixed this bug in RC-02 by reverting some of our improvements. These changes don't affect the new features—separate page for system fields and default values for the Description field, they’re still being shipped as planned.

You can read more about a specific use case related to this bug that was raised on our developer community.

Upgraded dependencies and libraries

Status: IMPLEMENTED (eap 01 and later)

Here's a list of dependencies and libraries that we've upgraded in this version:

Atlassian Troubleshooting and Support Tools

• Upgrade XStream from 1.4.10 to 1.4.15

Jira Importers plugin

• Upgraded sqlite-jdbc from 3.7.2 to 3.32.3.3
• Upgraded redmine-java-api from 2.2.0 to 3.1.2

Jira Core

• Upgraded XStream from 1.4.14 to 1.4.15
• Upgraded log4j from 1.2.17-atlassian-2 to 1.2.17-atlassian-3
• Upgraded commons-codec from 1.9 to 1.15
• Upgraded commons-compress from 1.8.1 to 1.18
• Upgraded hsqldb from 1.8.0.5 to 1.8.0.10
• Upgraded apache httpclient from 4.5.5 to 4.5.13
• Upgraded mortbaby.jetty (6.0.2) to eclipse.jetty (7.6.1.v20120215)

Jira Software

• Upgraded xerces from 2.9.1 to 2.12.1
• Upgraded commons-collection from 3.2.1 to 3.2.2
• Upgraded log4j from 1.2.16 to 1.2.17-atlassian-3
  
  

Using multiple identity providers (Data Center)

Status: IMPLEMENTED (eap 03)

You can now configure multiple Identity Providers (IdPs) in SAML and OpenID Connect configuration, and let your users choose the right one for them as they log in. All the new login methods can be enabled independently for customer portals in Jira Service Management.

To view and configure login methods:

1. Go to Administration > System.
2. Select Authentication methods (previously called SSO 2.0.)

When configuring your login methods, you can use the following pages for the details about how they should look:

• Setting up OpenID Connect single sign-on
• Setting up SAML single sign-on

Apart from adding and configuring new login methods, you can also disable basic authentication for the login page and API calls (described below).

Documentation

We're now adding these changes directly to Jira, but they have already been released as an update to the 'SSO for Atlassian Server and Data Center' app on the Marketplace. For more info and the docs, see Using multiple identity providers

Disabling basic authentication

Status: IMPLEMENTED (eap 03)

You can now disable basic authentication for the login page and API calls. Since we've added a way to configure single sign-on for multiple identity providers, we'll advise disabling basic authentication completely.

To disable basic authentication:

1. Go to Administration > System.
2. Select Authentication methods (previously called SSO 2.0.)

Documentation

We're now adding these changes directly to Jira, but they have already been released as an update to the 'SSO for Atlassian Server and Data Center' app on the Marketplace. For more info and the docs, see Disabling basic authentication.

More insights into custom field usage (Data Center)

Status: IMPLEMENTED (eap 02)

New columns with usage data

We've added two new columns that will give you more insight into the usage of your custom fields, so you can identify and clean up the ones you no longer need. You can view them by going to Administration > Custom fields.

Here's what they show exactly:

• Issues: The number of issues that have a value defined for a field. This includes issues with default values for a field, and archived issues. Refreshed once a day, and the date of last refresh is shown above the column (Issues: last refresh on...). The first data will be visible 24 hours after the upgrade.
  
  
• Last value update: The last time a value for a field was added or updated in any issue. Refreshed once an hour. Historical data won't be available for around 24 hours after the upgrade, but the new updates will appear as they come in. 

Good to know

• The columns are sortable, so you can easily find custom fields with no issues using them, or custom fields that haven't been updated for a long time.
• The Last value update columns comes together with a filter, so you can find custom fields that haven't been updated for 6 months, 1 year, 2 years, or since a specified date.

Bulk deleting custom fields

To let you easily delete all these unused custom field, we've introduced bulk editing. You can select multiple custom fields or all the ones visible on the screen if you used the filter.

REST API changes

We've made some changes to existing APIs and also introduced a new endpoint for bulk deletion.

{
    "message": "Custom fields bulk delete operation finished.",
    "deletedCustomFields": [
        "customfield_11089",
        "customfield_11098"
    ],
    "notDeletedCustomFields": {
        "notACustomField": "Custom field does not exist",
        "customfield_10201": "Custom field does not exist"
    }
}

Default values for the system fields (Data Center)

Status: IMPLEMENTED (eap 02)

We're introducing a possibility to configure a default value for the Description field. From now on admin can add and apply contexts with a default value to multiple issue types and projects.

We’ve added a new page to the administration area for the System fields to group out-of-the-box Jira fields. At the moment, you can add and apply different contexts with default values only for the Description field. For other fields, you can easily view the screens they’re associated with, and add some more if needed.

Improvements to DVCS accounts

Status: IMPLEMENTED (eap 02)

We've already made improvements to DVCS accounts in Jira 8.14, and now we're making them even better.

In this version:

• Significant user experience improvements for the whole DVCS accounts page, which was essentially redesigned
• New audit log events for the most important actions to let you troubleshoot more easily (Data Center)
• Improved search that lets you find accounts (organizations) and repos, and perform actions on them from the search results
• Improved integration process, with separated Bitbucket Cloud, GitHub, and GitLab accounts, and cleaned up screens related to the integration

Account view

Here's a sample view of your accounts—the first thing you'll see when opening the DVCS accounts page:

Repository view

And here's a sample view of your repositories, which you'll see after opening a specific account (similar view is displayed when you search for repositories):

Support for Microsoft Edge (Chromium)

Status: POSTPONED (Jira 8.17)

We're planning to add support for the Microsoft Edge (Chromium) browser. With this support, we'll also deprecate Microsoft Edge Legacy, planning to remove it in one of the next Jira versions.

Upgrading the icu4j library

Status: IMPLEMENTED (eap 01)

We're refreshing an old dependency, the icu4j library in Jira 8.16. The library is upgraded from version 3.8 to 68.2. On top of that, we're moving it from being provided through its own OSGi bundle into the application bundle. This means that explicit OSGi instructions may fail.

Why is it changing?

We have found a problem with the library, and we're afraid customers might encounter it, too. The library in its current version is not compatible with the latest OpenJDK updates and might cause Jira to fail in runtime.

What do I need to do?

Use the EAP1 to verify that your apps still correctly integrate with that library. If you encounter problems, you can fix them in two ways:

• Bring in your own version of the icu4j library with your app. This should work across many Jira versions.
• Test against the mentioned version, and try dropping explicit version requirement in your OSGi imports.
  
  

Removing fields from the JQL autocompletion

Status: IMPLEMENTED (eap 01)

We've removed jqlFieldz, jqlFunctionNamez, and jqlReservedWordz from the search pages for Jira 8.16. These fields provide data for JQL autocompletion. It used to be attached to all search-related pages even though it is only needed when an advanced search is used.

Why is it changing?

Calculating jqlFieldz, jqlFunctionNamez, and jqlReservedWordz is costly on large datasets and causing a performance slowdown.

What do I need to do?

Use data from REST resource instead of HTML fields according to the following guideline:

• jqlFieldz → visibleFieldNames
• jqlFunctionNamez → visibleFunctionNames
• jqlReservedWordz → jqlReservedWords