Preparing for Jira 8.17

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

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. 

Upgraded dependencies and libraries

Status: IMPLEMENTED

As announced in this post about security uplift, we’re putting more focus on upgrading core components and libraries in Jira to improve security. Here’s a list of libraries that we’ve already upgraded. We’ll update it as we release new EAPs:

Jira Core/platform

We’ve also fixed security vulnerabilities related to the following libraries/dependencies either by upgrading, changing, or excluding/removing them. If your app relies on any of these libraries, make sure to test it with the EAPs or check the source files for details:

• Apache Tika Core (transitive dependency removed in version 1.7)

• commons-net 3.7.2 (transitive dependency excluded)

• snakeyaml 1.15 (transitive dependency excluded)

• snakeyaml 1.8 (transitive dependency excluded)

• Jetty Server

• Jetty :: Asynchronous HTTP Client

• Jetty :: Server Core

• Jetty :: Utility Servlets and Filters

• Jetty :: Utilities

• Jetty :: Security

• Netty

• Netty/Codec

• Netty/Codec/HTTP

• Netty/Handler

Jira test suites migrated to Selenium 3

From now on Jira is using Selenium 3.141.59. We've adjusted Jira page objects. If you also use Jira page objects in your app, make sure you migrate your tests to Selenium 3.

Jira Service Management

Flexible Terminology for Jira (Data Center)

Status: IMPLEMENTED (eap 01)

As we informed you in Preparing for Jira 8.15, we enabled admins to change generic Jira terms and now we improved this feature even more. With this functionality, we give you a possibility to keep consistent naming of sprints and epics between Jira and the “Agile at Scale Frameworks” including SAFe and LeSS. Terminology changes apply to any variant of English and are synchronized with Advanced Roadmaps. Jira will keep capitalization of original terms whenever it's possible.

Feature overview

Here’s a summary of what’s available in this EAP:

• Managing terminology through Jira UI (available)
  
  Admins are able to change terminology directly in Jira. To view and manage your terms:
  

1. Go to Administration > System > Terminology
   
2. Click Change terminology
   
   You can define singular and plural forms of your new terms according to the following rules:
   
   • You can’t swap names of epics and sprints.
     
   • There is a 40-character limit.
     
   • Terms must be unique (e.g., epics and sprints can’t both be called “Potatoes”).
     
   • All fields must have a value (at least one char).
     

• Adjusting your app’s code to new terminology (available)
  To make your translated strings compatible with Flexible Terminology, you need to mark all supported terms with % characters. Those terms will get new names, configured by the Jira admin. If you, for some reason, want to keep the original names in your app even if users customized them in their Jira instance, don’t add these characters.

• Managing terminology through Java and REST APIs (available)
  You can view current terminology, change it, or be notified about the changes.
  
• Changes are visible around Jira (available)

With this functionality, terms will also be replaced in custom field names and issue types, and everywhere else in Jira, for example in reports, issues, and search results.

Limitations:

1. Terminology changes will apply only to English language variants. For other languages, Jira displays original names.

2. Whenever you change the term sprint in Jira, it will also be changed in Advanced Roadmaps. To have the term epic visible in Advanced Roadmaps, you need to make this change in Plans > Administration > Hierarchy levels.

3. Flexible Terminology uses translations of Custom Field and Issue Type to localize their UI names. As a result, all REST APIs will return localized names when querying the API or saving the issue (for example, new term). Also, new change items will be persisted with translated field’s name so querying for a field’s history should take into account all current and historical names of the field. If your app or script has a hardcoded reference to an issue type named epic or custom fields with the following names:
   

   • Epic Name

   • Epic Color

   • Epic Status

   • Epic Link

   • Sprint
     
     
   these need to be adapted to use IDs (recommended) or new names. You can do that by replacing epic or sprint with new terms, as returned by rest/api/2/terminology/entries.
   If your app and scripts are already using custom translations for Custom Fields or Issue Types, you don’t need to make any changes.

Exporting custom fields for Data pipeline (Data Center)

Status: IMPLEMENTED (eap 02)

We're working on making it possible for the Data Pipeline to export custom fields if they fulfill one of the following requirements:

• The custom field is created via Jira UI using a default custom field type (such as Select List, Text Field)

• The custom field uses a custom field type which implements the ExportableCustomFieldType interface from the public API (com.atlassian.jira.issue.export.customfield.ExportableCustomFieldType). It may apply to both default Jira custom field types and custom fields from plugins.

The exported custom fields will be added to the issue_fields_*.csv output file. There are no schema changes to this file at this point.

Versions

We're planning to release this feature with Jira 8.17. In Jira 8.16, this feature was hidden behind a dark feature flag, and we've enabled it in this EAP. 

Performance

Exporting custom fields may increase the total export time. Our investigation found that:

• For a dataset with 1 million issues, the export took ~7 times longer when all the custom fields were exported versus just the standard custom fields. The size of all of the output files in total increased ~2 times.

• For a dataset with 7 million issues, the export took ~5 times longer when all the custom fields were exported versus just the standard custom fields. The size of all of the exported files in total increased ~1.5 times.

The executions have been performed on c5d.9xlarge instance. The overall instance performance have been affected within acceptable thresholds (less than 5%).

Error handling

At the moment any type of failure related to the serialization of the custom fields during the export will make the export fail. Details of the job failure should be accessible via Data Pipeline job GET endpoint and the log files.

Support for Microsoft SQL Server 2019

Status: IMPLEMENTED (eap 01)

Jira 8.17 will support Microsoft SQL Server 2019. 

Support for Microsoft Edge (Chromium)

Status: IMPLEMENTED (eap 02)

Jira 8.17 will support Microsoft Edge (Chromium). We will also deprecate Microsoft Edge Legacy and remove it in the next version.

Removing legacy web-resource loading feature flag JIRA SERVICE MANAGEMENT

Status: IMPLEMENTED (eap 01)

We have removed support for the sd.frontend.legacy.webresource.loading.customerportal feature flag, and it will no longer function as intended. This includes using the feature flag as a workaround to load global web-resources in our pages.

Why is it changing?

The sd.frontend.legacy.webresource.loading.customerportal feature flag was included in 4.6.x as a fallback if global web-resources were expected to be in Jira Service Management.

As part of retaining our performance improvements, and reducing our technical debt, we are now fully committed to loading our pages asynchronously.

What do I need to do?

• Disable sd.frontend.legacy.webresource.loading.customerportal feature flag and test your apps behave as expected.
• If you require any global web-resources to be available in Jira Service Management, explicitly import them in your app. You can find a full list of these dependencies here

Removing JIM obsolete importers

Status: IMPLEMENTED

In Jira 8.17 we removed obsolete importers deprecated in Jira 8.4 from the codebase and they are no longer available. Jira 8.17 onwards will offer only CSV and JSON importers.
Importers provided by 3rd party plugins vendors won't be affected by this change.

How to turn this feature off?

In case it is critical for the customer to have the native importers re-enabled and the CSV/JSON path is not a viable option, it is possible to enable the deprecated importers through the dark feature flag jim.feature.show.deprecated.importers (How to manage dark features in Jira Server and Data Center). Make sure that in such case the customer is aware of using a deprecated and no longer supported feature which may lead to unexpected consequences as we no longer test the native imports.

Changes to installer/installation or upgrade process as part of this feature:

After upgrading to 8.4.0 or higher, the native importers will become unavailable by default.

Changes to APIs:

API structure did not change.

However, using a deprecated importer's name as {externalSystem} parameter will result in 403 errors for the existing, import-related endpoints. This may happen when for example when a REST request is sent to one one of the following endpoints and {externalSystem} is different than csv or json

• /rest/jira-importers-plugin/1.0/importer/{externalSystem}

• /rest/jira-importers-plugin/1.0/importer/{externalSystem}/log 

• /rest/jira-importers-plugin/1.0/importer/{externalSystem}/configuration 

• /rest/jira-importers-plugin/1.0/importer/{externalSystem}/status 

• /rest/jira-importers-plugin/1.0/importer/{externalSystem}/abort

This can also be switched off by the same dark feature flag.

Logging / visibility of the change in product:

• No new logging was introduced for the default state (when the native importers are disabled)

• If the jim.feature.show.deprecated.importers dark feature is enabled and the customer uses one of the deprecated native importers, a warning will be added at the top of the log report produced at the end of import process. The warning says "<importerName> is no longer supported. To migrate your data, import it to Jira in the CSV or JSON file format" 

• we've updated the plugins's descriptions in    > Manage apps > Manage apps to reflect the change.