Jira Service Management 5.9.x upgrade notes

Jira Service Management Release Notes

On this page

Still need help?

The Atlassian Community is here for you.

Ask the community

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

 Upgrade notes

Jira Service Management 5.9.0 has a known issue that breaks application links using OAuth with impersonation. This means the Jira Issues macro in Confluence and using Confluence as a knowledgebase with Jira Service Management may not work. We’ll deliver a fix for this problem in release 5.9.1.

Share requests with Jira groups DATA CENTER

Sharing requests with Jira groups will contribute to the scalability of the service desk and customer management in your instance. Jira Service Management projects can now leverage Jira's user management model to manage customers in internal service desks and take advantage of integration with Jira.

The feature brings several perks:

  • With this new feature, project admins and agents will be able to share requests from the Issue view with entire Jira groups added as customers of the service project. 
    New Groups field in the issue view
    1. New Groups field in the issue view
  • Project admins no longer have to rebuild internal customer groups within their organizations or manually add group members as request participants to grant them access to the requests. To efficiently manage permissions, you can use groups for internal customers and organizations for external customers.
  • This feature also extends the usability of existing feature like portal voting. For example, if a project admin wants to enable voting through the customer portal, they can simply build a pool of potential internal voters for a request without seeking individual access for each person. 
  • Project admins can additionally choose to extend the sharing capability to help-seekers, allowing them to easily share requests with Jira groups they’re part of on the customer portal, in addition to their organizations. For instance, if you’ve set up Jira Service Management as an internal help desk, your internal customers can quickly share requests with Jira groups.

    1. Dedicated checkbox Can customers share requests with groups? on the Customer Permissions page
  • Admins can create automation rules to share requests with appropriate groups, while agents can share requests with groups to collect insights from a larger internal audience through a single form.
    Set up automation rules to add groups

The customer email notifications rule for groups is set to off by default to reduce bulk notifications. You can change this setting from the Customer notifications page.

Learn how to share requests with groups

An upgrade task runs automatically in the background after your instance is up and running. This task adds the new Groups field to all your service projects in the GUI. This task can take a few minutes to complete if you have a large number of projects but it doesn’t prevent you from using Jira or Jira Service Management.

Run imports on dedicated nodes and track the progress of the operations DATA CENTER

As a part of our focus on Assets imports, Jira Service Management 5.9 includes the following improvements to the admin experience:

  • You can run manual imports on the same nodes that you configure for scheduled imports. A request for a manual import operation will send a cluster message to the other nodes, so only a dedicated node will handle the import. Having a dedicated node for resource-consuming scheduled and manual imports allows you to control the overall performance of a pool without scaling up every single node.

  • The progression of imports and other operations will be shared across all nodes and will be visible in the Process results tab on any node
    Progression of imports on a node
    Progression of imports on a node on the Process results tab

The progression of imports will also be shared across your database for the number of executed units of work that you can set in the Assets configuration. A unit of work quantifies the frequency of updates to the database for an operation in progress.

For example, in the case of a CSV import, a unit of work represents a single row in the CSV file where a row is an Assets object. For the interval of 100 units of work, the status of the import operation will be updated in the database every time 100 new objects are imported.

The default number of units of work is 100. To change this value:

  1. Go to Administration > Manage apps.
  2. In the left-side panel, select Assets configuration.
  3. Select Edit settings.
  4. In the Data Center section, edit the value of Frequency of updates for the status of an action in progress.
  5. Select Save.

Changes to the login-free portal signup flow DATA CENTER

When your customers submit their first request on a login-free customer portal, they'll receive an additional email recommending them to sign up for an account. This new experience offers them a convenient opportunity to create an account if they wish, which unlocks the logged-in experience and allows them to interact with their requests from the customer portal.

We’ve also backported these changes to versions 5.4 and 5.8.

Learn more about the login-free portal for JSM

Note that:

  • the email contains a secure signup token, which must not be shared with others
  • the token will automatically expire, after which the customer will need to reset their password to access their account
  • the customer will also receive an email confirming the creation of their request

Welcome email recommending user to sign up for an account

Enhanced email notification performance DATA CENTER

We've made several backend changes to customer email notifications to boost performance. These changes reduce notification delays and eliminate duplicate emails, while saving substantial CPU time on large instances. Notifying a large pool of recipients (groups and organizations that contain more than 100 members) will now be much faster.

Show or hide empty fields in the issue view DATA CENTER

Streamline the process of filling out empty custom fields, making them visible in the issue view by default. This is now possible with the new Empty custom field configuration feature that allows admins to show or hide custom fields in the issue view.

Empty fields displayed in the issue view will have the value of “None”, same as system fields. Project admins and Jira admins can change the visibility of empty custom fields in screen configurations, both at the project and instance levels. Learn more about permissions in Jira

Configuration on the instance level

Jira admins can turn on the Show when empty toggle from the Jira administation menu, on the Configure screen page:

  1. Screens tab. Here Jira admins can view all screens that have been defined in Jira.

  2. Show when empty toggle. When enabled, empty custom fields will be visible in the issue view.

Learn more about configuring screens

Configuration on the project level

Jira admins and Project admins can turn on the Show when empty toggle in the Project settings, on the Issue types and Screens tabs.

Change the visibility of empty custom fields on the Issue type page:

  1. View issue screen. Here Jira and Project admins can configure screens for different issue types.
  2. Show when empty toggle. When enabled, empty custom fields will be visible in the issue view.

Change the visibility of empty custom fields on the Screens page:

  1. Screens tab. Here Jira and Project admins can modify screen schemes and configure screens for different issue types.
  2. Show when empty toggle. When enabled, empty custom fields will be visible in the issue view.

Learn more about customizing issues in the project

More custom field improvements coming your way

The UI for this feature is still a work in progress and to offer the best possible user experience, it is not currently available by default. To access the new functionality, turn on the jira.customfields.configure.modern.ui feature flag.

Learn how to enable dark features in Jira

We've been working on custom field improvements for a while, shipping some bits of updates in recent releases. This version contains major updates for Jira admins as we enhance both the and feature configuration.

Remember that page where you could view all field's contexts and their setup? It got a new design and extended functionality:

  • You can now configure contexts and associate the field with issue screens on the same page. It only requires one click to switch between the settings of Contexts and Screens.

  • Forget about long scrolling. Instead, find the needed context by its name or description as we introduce the capability to search for contexts.

  • Screens are searchable as well — use the screen name to quickly find what you’re looking for.

  • Easily scan all context settings as we display the information in a table-style view.

  • Enjoy a faster and more efficient interaction with the page as it gets pagination and performance improvements.

A table with contexts configured for the custom field

  1. Context tab that lists all contexts configured for the “Development team” custom field.

  2. Contexts column: view contexts configured for the field and create new ones. Here you can also check:

    1. Issue types selected in a context.

    2. Projects selected in a context.

    3. The field’s default value that’s configured in a context.

    4. The field’s options that are defined in a context. Some Marketplace apps might automatically add options to this table.

  3. Actions menu: edit or delete a context.

  4. Add context button: create a new context for the field.

tip/resting Created with Sketch.

The information within the Contexts table might vary depending on the field type.

Such columns as Context, Issue types, Projects, and Actions are always displayed for any custom field. However, some fields that come from Marketplace apps can add custom columns to the table, instead of Default value and Options. The number of those columns and their contents are controlled and customized by the apps that created a custom field.

Learn more about configuring contexts for custom fields

Store your avatar data in Amazon S3

Introducing Amazon S3 to store avatar data is one more step toward our main goal: making S3 object storage available for every Data Center customer on , both for storing avatars and attachments. Stay tuned for more updates in the upcoming releases.

This release marks an important milestone — storing avatars in Amazon S3 is now available for Jira Service Management Data Center. You can keep your avatar data, such as user avatars, issue type icons, request type icons, and project icons in S3 buckets, instead of storing them in the <sharedhome> directory.

This means better scalability of your Jira app and more efficient data storage management, especially if there’s a growing amount of data on your instance.

Here’s what you need to know about the Amazon S3 configuration for Jira:

Learn more about configuring Amazon S3 object storage for Jira avatars

 End of support announcements

In Jira 9.9, we're announcing planned deprecation of the following platforms:

  • PostgreSQL 10
  • PostgreSQL 11
  • Oracle 12c R2

The support for these platforms will be ended in upcoming releases. For updates, check Jira Service Management release notes and Supported platforms.

 App developers

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

 Upgrade procedure

To help you upgrade to the latest and greatest:

  • 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 Sep 4, 2023

Was this helpful?

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