JIRA 5.1 in-depth analysis and review

Written on Jul 24 12 by Félix Martineau 3 comments

We present the new features of Atlassian JIRA 5.1, which was released on on July 9th 2012, and our Expert look at this release. I have skipped over some features on purpose because they generated no reaction when I found out, but I’d say I’m mentioning about 90% of new features here.

> Wish to upgrade your JIRA instance to 5.1 ? Contact us today <

 #1 Inline editing

This is definitely the main event of this JIRA 5.1 release. Inline editing allow you to modify issue fields when viewing an issue, without having to click on the Edit button. All you need to do is click on field and you’ll be able to edit it… provided you have that permission of course. This is all done without any page reload, so it’s definitely the fastest way to do a quick edit. If you know you’ll be editing several fields, it’s probably better to stick with the Edit button, because doing  five inline edits will trigger five “Issue Edited” notifications.

Demonstration of inline editing in JIRA 5.1

This new feature is also available via a keyboard shortcut. Press the comma key on your keyboard to bring up a pop-up, and start typing the name of the field you want to edit, then press enter to begin editing, and enter again when you’re done. Honestly, I think I’ll stick with using the “mouse version”, but it shows Atlassian is committed to keyboard shortcuts.

The keyboard shortcut version of inline editing in JIRA 5.1

#2 Fewer page reloads

Starting with JIRA 5.1, performing an issue operation will not cause the page to reload, even when a transition has a transition screen. It’s clear the focus of this release was about performance, and I feel Atlassian focused on the big wins. Saving one or two seconds for every JIRA operation will have a huge impact.

#3 The 200,000 issues limit is gone

Previously, Atlassian has recommended a soft limit of 200,000 issues per JIRA instance. You could go higher, but we were seeing performance drops past that limit. Atlassian has worked very hard on performance, and as the following graph shows, JIRA 5.1 brings a massive performance upgrade.

A graph comparing performance of JIRA 4.4.4 and JIRA 5.1

With this big performance boost, the soft limit of 200,000 is now a thing of the past, but I can’t help but wonder why Atlassian did not compare JIRA 5.1 with JIRA 5.0 instead.

 #4 Improvement of the JIRA configuration tool for databases

The JIRA configuration tool is used by administrators to the setup some JIRA properties. On a small instance you pretty much use it once and forget about it. With JIRA 5.1, there’s a new Advanced tab that allows you to setup a bunch of new properties for your database connection, something very important for a large enterprise instance.

The new Advanced tab in the JIRA Configuration tool

#5 Database monitoring page

Another new feature that JIRA Administrators are sure to enjoy is the Database Monitoring page. For small instance this will not be very important, but I can tell you I would have liked to have that page when searching for performance bottleneck on a large instance, so it’s great addition. It’s great to see Atlassian starting to deliver Enterprise features, which shouldn’t come as a surprise with the new JIRA Enterprise licence tier.

Database Monitoring screen

#6 Issue Collector

The issue collector is brand new feature in JIRA that allows you to easily embed a form in your web site, contents of which will be sent to your JIRA instance. It’s a great way to get feeback for your users / clients and tie it with JIRA notifications and workflows. To create an issue collector, you must be a Project Administrator and go to the Project Summary screen where you’ll be able to generate the HTML and javascript. I one of our old projects, we coded a custom form to receive feedback and send it to JIRA through email, so the issue collector will be very useful.

The issue collector in JIRA 5.1

#7 – Improvements to workflow editing

I won’t lie, I was initially confused when I wanted to edit a workflow in JIRA 5.1, during a client presentation no less, but after 2 minutes, I can say the changes make perfect sense. You can now edit a workflow directly form the Project Summary screen, and JIRA will take care of all the workflow copying that must happen. Also, workflow drafts are managed “behind the scenes”, meaning that you automatically work on the draft version of a workflow, without having to look for that draft in your list of workflows. For large JIRA instances with several workflows, it will definitely remove a lot of clutter. As you can see in the following screenshot, the Publish Draft action has become a button instead of the blue bubble it used to be.

The visual workflow editor in JIRA 5.1 with interface improvements

 #8 Productivity improvement to some Administration tasks

Sometimes it’s the little things that make an impact. Buried in the release notes for JIRA 5.1, we find out that when you add a screen, a screen scheme, a field configuration, field configuration scheme or an issue type screen scheme, you’ll get taken directly to its configuration screen. This may sound pointless for most, but if you’ve ever worked on a large instance with tons of screen, this will save you the hassle of locating the right “Configure” link, a task that was similar to playing “Where is Waldo”.

#9 User deactivation

You can now easily deactivate a user by going to the “Edit User” screen and clicking on a new checkbox to deactivate the user. Before, you had to remove the user from all the groups that has the Global Permission JIRA Users. I went in my JIRA 5.1 and verified that deactivating a user preserves its groups, which is handy if you ever need to reactivate it later. For me, it’s not a big ticket item, but I hope this will lead Atlassian to address a similar problem in Confluence, where deactivated users still show up in search results.

How to deactivate a user in JIRA

In more details, here is what happens when you deactivate a user:

  • Will no longer be able to log in to JIRA.
  • Cannot be assigned issues or added as a watcher to issues (whenever issues are created or edited).
  • However:A user who was assigned, was watching or had reported any issues in JIRA before their account is deactivated, will still appear as the respective assignee, watcher or reporter of those issues. This situation remains until another user is specified as the assignee or reporter of these issues, or the deactivated user is removed as a watcher from them.
  • A user who voted on any issues in JIRA before their account is deactivated, will continue to appear as a voter on these issues.
  • Will continue to appear on the JIRA user interface with ‘(Inactive)’ displayed after their name, where applicable.
  • Can still be used to filter issues in a JIRA search query.
  • Will not receive any email notifications from JIRA, even if they continue to remain the assignee, reporter, or watchers of issues.
  • Will not count towards your JIRA user license limit.


  • Users who are project or component leads cannot be deactivated. To deactivate these users, assign other users as the relevant project or component leads first.
  • Any JIRA site’s users who are configured in an external Atlassian Crowd user directory and deactivated in Crowd, will be deactivated in JIRA.
  • With the exception of JIRA users configured with ‘delegated LDAP authentication’, JIRA does not deactivate users who are configured and deactivated/disabled in an external Microsoft Active Directory or LDAP-based user directory.

#10 ’Autowatch’ issues you create or comment on

That feature used be available through a JIRA plugin, so it’s not a huge deal, but this reinforces Atlassian’s will to make its tools as social as possible. By default, every user will autowatch issues they create or comment on, but it can be deactivated through user properties.

How to deactivate autowatch in JIRA

#11 Improvements to the Link Issue fucntionnality

I can’t say issue linking is the most used feature by our clients, but I really like the improvements Atlassian made to the Link Issue screen. First of all the JIRA Issue (local to your instance) and Remote JIRA Issue tabs have been combined. You can also use JQL to find the issue you wish to link to. It may prove useful if you need to link several issues, but it’s more a nice-to-a-have.

The improved Link Issue screen in JIRA 5.1

#12 Notify on my actions disabled by default

Another one of those smaller improvements that’ll save a lot of time. New users now have the “Notify me on my actions” disabled by default. That’s great because new users tend to complain about getting too many emails, so this will do wonders.

#13 My JIRA home

Now you can select where you end up when you log into JIRA. Before, the user would see the last dashboard they had looked at, but now you have the choice of “landing” on the Issue Navigator, or stick with the dashboard. GreenHopper users can also choose the “Agile” tab. Not sure why I’d select the Issue Navigator instead of the dashboard, but I can definitely see why one would choose the Agile view.

Choosing your JIRA Home

#14 Launch HipChat notifications from workflow transitions

It was only a matter of time before Atlassian started integration HipChat with JIRA, so here we are with HipChat notifications from workflow transitions. There’s new post-function called Notify HipChat that works with the following parameters:

  1. (optional) Specify a JQL function, if the issue matches the JQL criteria, a notification will be sent
  2. Specify the HipChat rooms you want to notify

Closing remarks

JIRA 5.0 was released on February 22nd, so it took roughly 5 months for Atlassian to push out JIRA 5.1. This is a strong release for JIRA, one that addresses key issues (no pun intended) such as Enterprise concerns like performance, database configuration and monitoring. For users, the main change is of course inline editing which a huge deal, but you might want to turn “Issue Edited” notifications, because each inline edit will trigger one.

The issue collector is cool, but we already had seen something similar with JIRA Mobile Connect, so I’m not doing backflips over it. I really appreciate the little improvements here and there, especially in the Administration section. So cheers Atlassian !

> Looking for an Atlassian Expert ? Contact us <

Tags :


  1. Dana says:
    Wednesday, August 1, 2012 at 7:24am

    Nice article. You hit on a bunch of the new features and there are a few notable ones.

    Saying the 200,000 issue is “gone” is a bit of hyperbole. Looking at the chart, there is certainly an good speed improvement but it seems to me that the 200,000 limit just became the 500,000 limit (same speed at that number). Maybe I am just looking a gift horse in the mouth :)

    I wonder if you can “deactivate” users properly when using crowd. We are still stuck with the issue that custom “User Picker” fields will show all users in the dir synced with JIRA even if the users are removed from all groups. Its a know bug in 5.0. It would be nice if this somehow fixed that issue.

    I also wish that Atlassian would focus on fixing old/nasty bugs instead of always just adding new features. I would certainly address the lack of bug-fixes in a new major release if it was evident that some issues have not been fixed. For example the Cascading Select is buggy and clunky and I don’t see a fix for that. Much like the crowd/user issue etc. This has been my main issue with Atlassian in the short time we have used the product. They don’t seem to fix as many old/outstanding issues with the past few releases as I would like to see.


  2. Félix Martineau says:
    Wednesday, August 1, 2012 at 1:58pm

    About “deactivating users properly”, I’m pretty confident (95%) Crowd will not solve this problem. The real problem is with the User Picker, fetching every JIRA user. There is a very similar problem in Confluence too.

    I share your opinion about “Atlassian should fix old bugs”. Some very popular issues have been opened for several years, and it always pains me to see how Atlassian will just put a generic comment saying they won’t address it anytime soon. I enjoy the transparency, but I don’t like to feel powerless, especially for stuff that seems super obvious for me… and several hundred voters.

    I’ll probably do a post later just about these bugs/features that should be fixed.


  3. Dana says:
    Monday, August 6, 2012 at 12:45am

    Its just surprising when the fix is so simple, don’t list people who are not in the “jira-users” group. Thats it. And it causes usability issues.

    My top bugs that should be easy to fix but have been open for a while…

    1) User Picker (as mentioned)
    2) Cascade Select: Gives errors when user tries to clear unless they pick “Please choose…” which makes no sense to the end user.
    3) Defaults per project broke after 5.0 upgrade. It won’t set the proper default anymore.


Post a Comment

Your email is never published or shared. Required fields are marked *