Jira Software 8.14.x upgrade notes

Older

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

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


 Upgrade notes

Known issue: Email notifications failing on Windows instances

With the introduction of new email templates for Jira Data Center, we’ve let a bug slip that makes email notifications fail on Windows instances. Until this bug is fixed, we recommend that you disable the email templates feature (described below) if you’re upgrading on Windows. For more info about this bug and updates, see:  JRASERVER-71988 - Getting issue details... STATUS

To disable new email templates:

  1. Edit the <Jira-install-dir>/atlassian-jira/WEB-INF/classes/jira-features.properties file.
  2. Search for the com.atlassian.jira.email.templates.readFromJiraHome setting, and set it fo false. Here’s an example: 

    com.atlassian.jira.email.templates.readFromJiraHome=false
  3. Save the changes.
  4. If you already started your Jira instance, restart it. 

After making these changes, Jira will use the bundled templates (like it did in previous versions) instead of the custom ones from your Jira shared home directory.

8.14.1: Changes to the allowlist

When you create an application link, the URL is automatically added to the Jira allowlist. From Jira 8.14.1, 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. 

Changes to email templates (Data Center)

As you might have read in the release notes, we've made improvements to email templates that control your notifications. For details about this feature, see Customizing email content.

Here's a summary of changes you need to know about right now:

  • Different way of accessing templates
    You can now download your templates directly from the Jira administration. All available templates will be downloaded as a ZIP archive. Once you modify them locally, you can upload them back to Jira, and we'll move them to all the right places for you. The templates are available at Administration > System > Email templates.

  • Different location of active templates
    The templates you upload to Jira will be moved to your Jira shared home directory so you can retain your changes on future upgrades. What's important is that we'll copy the default Jira templates to your shared home directory during the upgrade. The default templates are what you would previously retrieve from Jira resources or one of the plugins (batched issue notifications). These will be then default Jira templates without any modifications.

  • Recommended actions
    After you upgrade Jira, we recommend that you don't update the templates in the usual way (by copying your modified templates to the Jira install directory or the plugin), but instead download the ZIP archive from the Email templates page, edit the templates locally (or switch the files), and upload it back. In this way, your modified templates will be moved to the shared home directory, and the default ("empty") templates will remain in Jira resources in case we needed to fall back to them.

Linking a GitLab repository with Jira

We've made a number of performance improvements to the DVCS Connector bundled with Jira. You'll definitely see the difference when viewing your DVCS accounts. Another improvement in DVCS is support for GitLab. If you'd like to learn how to link your Gitlab repository with Jira, see:

Project status available in API project list

We've added a new parameter to the project REST API. Now, when you fetch your list of projects with rest/api/latest/project you'll get an archived:true or archived:false parameter for every project in the list.

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.

Change in logging in with passing credentials in URL parameters

We're blocking the default possibility to log into Jira by passing credentials via URL parameters. For details, see  JRASERVER-38548 - Getting issue details... STATUS

Deprecated method

This method of authentication has been deprecated since Jira 8.0 (11 Feb 2019). For details, see  JRASERVER-67979 - Getting issue details... STATUS

Reason

Since the credentials might end up as a plain text entry in different log files (such as that of load balancers or proxies), this method poses a security risk. To mitigate it, we want to block its default availability, and make it an option only in special cases. We’ll also sanitize the access logs of the Tomcat web server bundled with Jira.

However, for the internal and legacy integrations to keep working, we still want to provide a way to use this method. You’ll have to set the special system property atlassian.allow.insecure.url.parameter.login to trueThat way your legacy and/or internal integrations will still work. To keep your logs under control, it’s also a good idea to review your logs for possible credential entries.

 End of support announcements

There are no changes in this release. For details on what's supported, see Supported platforms.

 App developers

See Preparing for Jira 8.14 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. 

  • For a more tailored upgrade, go to Jira administration > Applications > Plan your upgrade. We’ll recommend a version to upgrade to, run pre-upgrade checks, and provide you with a custom upgrade guide with step-by-step instructions.
Last modified on Jan 18, 2021

Was this helpful?

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