Jira Service Management 4.14.x upgrade notes
Below are some important notes on upgrading to Jira Service Management 4.14. For details on the new features and improvements in this release, see the Jira Service Management 4.14.x release notes.
Summary of changes
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:
- Edit the <Jira-install-dir>/atlassian-jira/WEB-INF/classes/jira-features.properties file.
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- Save the changes.
- 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.
4.14.1: Changes to the allowlist
When you create an application link, the URL is automatically added to the Jira allowlist. From Jira Service Management 4.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.
Jira Service Management: what's changing
As you might have read in the release notes, we're rebranding Jira Service Desk to Jira Service Management. This change emphasizes our move into the IT service management (ITSM) area and brings Jira Service Desk to the next level. Although we're changing the product name and most occurrences of Service Desk in Jira, there are still some things that we're leaving untouched, at least for now.
What doesn’t change in this version
All roles and permissions: To make things easier, we decided to keep current roles and permissions intact. This includes roles like Jira Service Desk Customer - Portal Access or Service Desk Team. We might change them in future releases, but we’ll let you know when that happens.
- URLs: URLs to pages around Jira Service Management haven't been updated. This includes the base URL which includes the
servicedesk/context. - Existing entities (workflows, schemes, etc.): We won't change the names of your existing entities, but we will change them for new entities. For example, when you create a new project, it'll use the Jira Service Management default workflow.
To learn more about Jira Service Management and our exciting plans for the future, see Get to know Jira Service Management.
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.
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 true. That 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
- 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.