Jira Service Desk 4.13.x upgrade notes

Below are some important notes on upgrading to Jira Service Desk 4.13. For details on the new features and improvements in this release, see the Jira Service Desk 4.13.x release notes.

 Summary of changes

Upgrade notes

We normally do not introduce new features in the Long Term Support release but rather consolidate the ones we've introduced since the last Enterprise releases. See our change log for all the features and fixes between the last LTS releases. Learn more

Security advice: Allowing customers to raise requests

We’ve published a security advice regarding the setting “Anyone can email the service desk or raise a request in the portal” that can be set in Administration > Applications > Jira Service Desk configuration. If you’re using this setting, make sure to read it. For more info, see Managing access to your service project.

4.13.12: Support for PostgreSQL 12 and Amazon Aurora PostgreSQL 12

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

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

Jira Service Desk 4.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.

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:

• MySQL 5.7 Reference Manual — 2.11 Upgrading MySQL
• Connecting Jira applications to MySQL 5.7

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:

• MySQL 5.7 Reference Manual — 2.9.6 Configuring SSL Library Support
• Connecting Jira applications to MySQL 5.7

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

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.

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

4.13.4: Known issue: Performance of user actions on issues

We’ve discovered an issue, where background reindexing might affect the performance of users actions on issues (create, update, comment). This was already introduced in Jira Service Management 4.10. While we’re working to fix it, we’ve decided to not block this release, as the issue already exists in your Jira instance, and you can still benefit from other fixes included in this release.

We want you to be aware of this issue, so you can work around it, if needed. We’ll update these upgrade notes once we release the fix.

Learn more about the issue and workarounds

4.13.3: Changes to the allowlist

When you create an application link, the URL is automatically added to the Jira allowlist. From Jira Service Management 4.13.3, outbound requests from these URLs require users to be authenticated, unless you specifically allow anonymous users.

In addition, you can also set the default allowlist behavior for all application links. Choose to allow all users (including anonymous), only authenticated users, or deny all outbound requests for all users. When a new application link is created, the URL will be added to the allowlist with your preferred setting already configured. 

If you experience any issues with features that rely on application links, such as gadgets, you can choose to allow anonymous requests for that application link. This is less secure, but may be a useful workaround until you can make any required changes to your linked application for authenticated requests. If you are in this situation, consider using an exact URL or wildcard rule to limit access to only the required path or resources. 

If you subscribe a third-party gadget that doesn't require an application link, you will now need to add the gadget URL to the allowlist. 

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 Service Desk 4.12.2 and 4.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

• 4.12.2, 4.13.0

Fixed versions

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

• 4.12.3, 4.13.1

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:

• Connecting Jira to MySQL 8.0
• Connecting Jira to MySQL 5.7

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 Service Desk 4.13, we're not making any changes. For previous announcements, see End of support announcements.

App developers

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

Upgrade procedure

We've prepared a dedicated upgrade guide for upgrading between Enterprise releases. See Long Term Support release upgrade guide.