Jira Core 8.13.x upgrade notes

Jira Core release notes

On this page

Still need help?

The Atlassian Community is here for you.

Ask the community

Here are some important notes on upgrading to Jira Core 8.13.

For details on the new features and improvements in this release, see the Jira Core 8.13.x release notes


 Upgrade notes

8.13.12: Support for PostgreSQL 12 and Amazon Aurora PostgreSQL 12

Jira 8.13.12 adds support for PostgreSQL 12 (Server and Data Center) and Amazon Aurora PostgreSQL 12 (Data Center only). Additionally, this version of Jira is tested and bundled with version version 42.2.23 of the PostgreSQL JDBC driver.

Jira 8.13.12 has a known issue, where the Supported database health check fails incorrectly on instances of Jira running on PostgreSQL 12. We are working on delivering a fix as soon as possible.

8.13.9: Bundled JRE disables secure connections to MySQL Community Edition 5.7.27 or older over TLS versions 1 and 1.1

Jira 8.13.9 binary installers are bundled with the AdoptOpenJDK 8u291 JRE, which ships with TLS versions 1 and 1.1 disabled by default. This prevents secure connections with MySQL Community Edition 5.7.27 or older compiled with yaSSL.

You're not affected by this issue if:

  • You’re running MySQL Enterprise Edition
  • You’re running MySQL Community Edition 5.7.27 compiled with OpenSSL
  • You haven’t enabled secure connections in MySQL Community Edition
  • You’re running Jira using a JRE version lower than 8u291 or 11.0.11

To ensure that Jira can establish a secure connection with your MySQL database after the upgrade, switch to a version of MySQL Community Edition that supports TLS 1.2. You can choose one of the following solutions:

Recommended solution: Upgrade to MySQL Community Edition 5.7.28 or newer

Because the binary distributions of MySQL Community Edition 5.7.27 and older are compiled with yaSSL, they do not support TLS 1.2 by default. We recommend that you upgrade to MySQL Community Edition 5.7.28 or newer (this version uses the OpenSSL library), and then allow secure connections over TLS 1.2 by either:

  • Upgrading the MySQL Connector/J driver to version 8.0.19 or newer.
  • Adding the enabledTLSProtocols=TLSv1.2 parameter to the MySQL JDBC connection string in dbconfig.xml.

For more information, see:

Solution 2: Recompile MySQL Community Edition 5.7.27 or older with OpenSSL

Alternatively, you can recompile version MySQL Community Edition 5.7.27 or older with OpenSSL, and then allow secure connections over TLS 1.2 by either:

  • Upgrading the MySQL Connector/J driver to version 8.0.19 or newer.
  • Adding the enabledTLSProtocols=TLSv1.2 parameter to the MySQL JDBC connection string in dbconfig.xml.

For more information, see:

Solution 3: Re-enable TLS 1 and 1.1 in Java

The TLS 1 and 1.1 protocols are insecure. Atlassian does not recommend using this solution in the long term.

If required, you can re-enable support for TLS 1 and TLS 1.1 in Java by removing the TLSv1 and TLSv1.1 entries from the jdk.tls.disabledAlgorithms property in <JAVA_HOME>/lib/security/java.security.

8.13.7: Changes in startup files

We've changed several startup files to change the format of GC logs produced by Jira while running with Java 11. Without the change, the logs are impossible to parse with the GCViewer tool and can be frustrating for an admin to work with. 

We've changed the time,uptime to tags,time,uptime,level in the following files:

  • bin/set-gc-params.sh file on Linux
  • bin/set-gc-params.bat file on Windows
  • bin/set-gc-params-service.bat file on Windows

If you don't have any custom changes in those files, you don't need to take any cation. If you do, you'll need to copy your changes to the new files on upgrade.

Known issue: Modal dialogs don't open on pages that use cross-origin iFrames

A number of actions in Jira are configured in modal dialogs (pop-ups) — for example, when you click Edit next to an item, we’ll often open the edit settings in the modal rather than move you to a separate page.

Problem

In Jira 8.12.2 and 8.13.0, these modal dialogs might not open on pages that use cross-origin iFrames. An example of this could be a cross-origin iFrame added to the Jira banner to collect some statistics. Because of this problem, you won’t be able to complete actions that rely on modal dialogs — these might include editing permissions, starting sprints, or editing comments in Jira Service Management requests.  More about this bug

Affected versions

  • 8.12.2, 8.13.0

Fixed versions

We have already fixed this problem in the following bugfix releases:

  • 8.12.3, 8.13.1

Support for Microsoft Exchange Online POP3 (8.13.1+)

We are planning to add the option to integrate with OAuth 2.0 using POP3 for Microsoft Exchange Online. The support will cover OAuth 2.0 integration for incoming mail. 

Setting to prevent phishing attacks 

To prevent non-authenticated users from navigating to crafted URLs in Jira and injecting messages onto the page, we've added a setting that disables displaying URL parameters in security dialogs. 

The setting is available in Jira administration > System > General configuration and defaults to Off

If the setting is disabled, the URL parameters that might be added to a URL are not captured and displayed in security dialogs. In that case, a security dialog looks the following:

New system property to speed up database search

We're introducing a new mechanism that retrieves custom field values for issues in batches of 50. This speeds up time-consuming operations such as database search. 

For now, all these improvements affect only Jira built-in custom fields. We’re also opening an experimental API to help you leverage these improvements. For details, see Batch custom field value retrieval API

You configure this feature with the jira.custom.field.indexing.batch.size property. Setting its value to 1 disables batching and any other number defines the number of issues that will be batched. 

To benefit from this change, a full reindex needs to be performed.

Known issue: Jira doesn’t recognize a MySQL database after the upgrade

If you're using a MySQL database, you might get the following error after the upgrade:

We can't tell what database you're using

That’s because your dbcongig.xml file is using mysql as the database-type. This type is no longer recognized by Jira after we ended support for MySQL 5.6, so you’ll need to update it.

To solve this issue:

  1. Stop Jira.
  2. Edit the dbconfig.xml file (in your home directory)
    • If you’re using MySQL 8.0, change the database-type to mysql8.
    • If you’re using MySQL 5.7, change the database-type to mysql57.
    • If you're using MySQL 5.6, you will need to upgrade your database first, as this version is no longer supported.

For more info about connecting Jira to MySQL, see:

Known issue: Azure SQL is reported as an unsupported database

If you’re running Jira with the Microsoft Azure SQL database, you will get warnings saying that you’re using an unsupported database. That’s because Azure SQL is mistakenly reported as SQL Server 2014, and we’ve ended support for this one in this release.

Solution: 

We’re working on the update of the Atlassian Troubleshooting and Support Tools app. For now, discard the warnings and wait for the available update. Your database is fine.

Increase pool-max-size

If you're upgrading from Jira 7.x to Jira 8.x we recommend changing the pool-max-size parameter to 40 in your dbconfig.xml before the upgrade. Leaving the default of 20 can sometimes lead to “ResultSet Closed” errors during re-indexing on 8.x. For information on implementing the change, see  Tuning database connections .

An important bugfix requires full reindex

We fixed a bug that caused issues removed from sprint not showing in Burndown Chart or Sprint Report. The problem will automatically be fixed for all the newly created and edited issues and they will display in the Sprint Report and Burndown Chart.
If you are not concerned about the past issues, you don’t have to take any action. However, if you want to be sure all the past and current issues get fixed too, you need to perform a full reindex.

A bug in Tomcat causing issues on upgrade

Tomcat started to use double-quotes as of version 8.5.48 as a result of Expansion of JAVA_OPTS in catalina.sh containing '*' stops startup on linux bug. That's why when you upgrade to Jira 8.13 and set parameters in setenv.sh or setenv.bat, make sure that you:

  • Don't remove the double-quotes in the catalina.sh
  • Set all your parameters in one line without any new line in setenv.sh or setenv.bat

Otherwise you might experience issues starting up Jira. 

New events in the Advanced audit log DATA CENTER

We are adding new events to track priority (Created, deleted updated) and secure admin login (websudo) for you to have better insight into your application. 

Known vulnerability in the BKS-V1 keystore format

If you’re running Jira over SSL, we’d like to bring your attention to a security vulnerability of the BKS-V1 keystore format, provided by the BouncyCastle library. We strongly recommend that you don’t use it in your Jira instance. Learn more

 End of support announcements

In Jira 8.13, we are not making any changes. 

App developers

See Preparing for Jira 8.13 for any important changes regarding apps.

Upgrade procedure

Upgrading from a Jira version 8.x.x? 

See  Upgrading Jira applications  for complete upgrade procedures, including all available upgrade methods and pre-upgrade steps.

Last modified on Oct 19, 2021

Was this helpful?

Yes
No
Provide feedback about this article
Powered by Confluence and Scroll Viewport.