JIRA Service Desk 3.6.x release notes

Release notes for earlier versions of Jira Service Management

On this page

Still need help?

The Atlassian Community is here for you.

Ask the community

This JIRA Service Desk release has reached its end of life. See End of life policy.

29 June 2017

The Atlassian JIRA Service Desk team is proud to announce the release of JIRA Service Desk 3.6.

The JIRA Service Desk development team has been working on releasing more frequently, and this release includes both JIRA Service Desk and JIRA platform features. In this release, our top features include:

  • new SLA rendering, to make the values more understandable and useful,
  • the ability to enable the extended project administrator permission on a per project basis,
  • extending the project administrator permission to include editing screens,
  • zero downtime upgrades for JIRA Service Desk customers, and
  • an improved issue export experience.

This isn't all we've done, we've also made a few minor tweaks, listed below, and we've been busy fixing bugs to improve the overall experience with JIRA Service Desk.

We believe we've been working on the right things to improve the JIRA Service Desk experience for our full customer base. Of course, we can't do that without your comments and suggestions, so please feel free to send them directly to us in our JIRA instance.

Hope you enjoy JIRA Service Desk 3.6!

Warren Thompson,

JIRA Service Desk technical writer

On this page:

Download the latest version
Or upgrade your existing JIRA Service Desk application.

Compatible applications

If you're looking for compatible JIRA applications, look no further:

SLA rendering

Have you ever looked at an SLA that says something like "-881:00" and realised that while you know that's probably bad, you have no idea how bad? Well, In JIRA Service Desk 3.6, we decided it was time to make those figures more readable. Now, instead of something like "-48:00", which you may think indicates 2 days, we'll render the SLA as something like "-1w 1d", based on your calendar settings. In this example, we've taken calendar settings of a 5 day week, with 8 working hours a day. As you can see, the difference between thinking "-48:00" means 2 days, and the correct time frame of 1 week and 1 day is pretty large!

We hope that this change removes the ambiguity around SLAs, where you need to remember your SLA's calendar settings, and gives you a figure which is not only more readable, but also helps build empathy with your customers, as you'll know in real terms how long they've been waiting. Hand in hand with this, we've also adjusted the hover state, so when you hover over an SLA, you're given more pertinent information that helps your agents know exactly what state the request is in.

For more information read How teams see SLAs.

Project level administration

In JIRA Service Desk 3.5, we allowed project administrators to edit their project's workflows under specific conditions. Now, we've added morefine-grained control to the Administer Projects permission, and added a few more perks for the project administrator.  When granted, the Extended project administration permission will allow project administrators for the associated projects to:

Edit the project's workflow, expand to see the restrictions
  • The workflow must not be shared with any other projects, or be a system workflow.
  • To add a status, the status must already exist in the JIRA instance i.e. the project admin can't create new statuses or edit existing statuses.
  • To delete a status, the status must not be used by any of the project's issues.
  • The project admin can create, update or delete transitions, but they can't select or update a screen used by the transition, or edit or view a transition's properties, conditions, validators or post-functions.
Edit the project's screens, expand to see the restrictions
  • The screen must not be a default system screen.
  • The screen must not be shared with any other projects, or used as a transition screen in workflows.
  • The project admin can add, remove and rearrange system fields.
  • The project admin can add, remove and rearrange existing custom fields, but they cannot create custom fields.

The Extended project administration option is enabled by default. if you're a JIRA administrator, you can disable it by selecting   > Issues > Permission schemes, and then choosing the relevant permission scheme to edit. Project and JIRA administrators can also view the Extended project administration setting when they're viewing their project by selecting Project settings > Permissions, however the JIRA administrator can't edit the setting here.

JIRA Service Desk Data Center Zero downtime upgrades

JIRA Software 7.3 introduced the ability to upgrade their Data Center deployment with zero downtime, and we're pleased to announce we've implemented this for JIRA Service Desk Data Center deployments. This means that is JIRA Service Desk is mission critical for your organization, you will be able to upgrade moving forward with zero downtime for your users. Effectively, what you'll do is upgrade your nodes one at a time, and when they're all upgraded, finalize the upgrade. No downtime is achieved through at least one node always being available. You can read up more on zero downtime upgrades in our administration documentation.

Improvements to issue export 

We've implemented an exporter which exports JIRA issues in an HTML format. When viewing a list of issues, select  > HTML (All fields) or  > HTML (Current fields) . If required, a JIRA administrator can disable the HTML export option by setting the jira.export.html.enabled property to false at  > System > Advanced Settings.

Given that the HTML export can be quite memory intensive in large JIRA Software instances, we've also added two additional properties to the Advanced Settings page. These properties allow a JIRA administrator to control the default number of search results allowed to be exported by a user (jira.search.views.default.max) and the absolute maximum number of search results allowed to be exported (jira.search.views.max.limit). This allows an admin to prevent users from attempting to export a large number of results, which could result in performance problems with your instance.

In-app notifications

We've implemented a system add-on which provides targeted notifications within your JIRA Service Desk instance, predominantly to JIRA administrators. These notifications will alert you when new JIRA versions are available, and of upcoming license renewals. The in-app notifications are delivered by a system add-on, and can be controlled by selecting  > Add-ons > Manage add-ons, and then filtering for Atlassian Notifications. We actually shipped this in JIRA Service Desk 3.5.2, but we're just making sure you know about it. You may even be reading these release notes because you've been directed here by an in-app notification.

More improvements

We've added a few smaller enhancements, all designed to make the user and admin experiences a little easier and more efficient:

  • The "Shared by" lozenge  has now been replaced with a "Used by" lozenge .
  • We’ve improved navigation around editing workflows and introduced the draft mode that allows you to easily quit editing if you don’t want to publish your changes. Also, you can now edit your workflows in the Workflows section of the Projects settings instead of going to each issue type.

  • We've added more events to the audit log that allow admins to view changes to their project's workflows and screens, so they'll know who changed what, andwhere,if they ever need to roll back a project's settings.
  • We've improved the garbage collection logs, and they're now generated automatically, you'll be able to find them in your logs at <installation-directory>/logs.
  • We've improved our error reporting for installations and upgrades to make it more informational, added details on possible resolutions, and links to more information.

Resolved issues

Performance issues

We’ve noticed that versions 3.6.0, 3.6.1 and 3.6.2 have performance issues and show errors while opening pages or finishing some actions. This applies only if you’re using postgreSQL and have more than 500k users. To work around it, increase the heap size by 1GB per million users. We’ll release a fix for this in the next bugfix release.

Last modified on Jul 22, 2019

Was this helpful?

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