JIRA 6.2: Be Better than Yesterday

Atlassian JIRA is one of the most famous and popular issue trackers nowadays. Moreover, a lot of companies all over the world use JIRA not only as an issue tracker, but also as a project management system. JIRA is fairly flexible for solving a large number of seemingly unrelated tasks, it can be easily enhanced by developing additional plugins.

Every time users of Atlassian products wait for the next major release with a feeling that it will be better than the previous one. That’s why everyone has only positive expectations from JIRA 6.2 that was officially released on February 25th.

This post will analyze what’s new in the new JIRA version.

A New View on the Development Tools Integration

Many users love JIRA for its easy integration with other Atlassian created tools for developers:

• Stash — a self-hosted Git repositories management system
• Bamboo — continuous integration system
• Bitbucket — Git and Mercurial repositories management system
• Crucible — code review system

The new JIRA version offers a new view on developer tools integration. Now, every issue has the Development section which is a starting point for developers and product managers. The info in this section let them understand what has already done for the issue and what is to be done.

You can see the list of branches, commits and pull request connected to the issue from Stash right in JIRA:

Or, you can quickly check, for example, the build and deployment history from Bamboo:

Moreover, you can create a new branch and start developing a new functionality right in JIRA.

«Remember Now thy Creator»

For a long time it was impossible to view a name of an actual issue reporter. Although there’s the reporter name, it should be noted that:

• the field is optional and usually it’s not displayed in the issue window
• the field is editable and its value can be easily changed at any time

As a solution to this one of the oldest JIRA’s problems was easy-to-implement approach of saving a reporter’s name in issue history and displaying it in the issue window:

Interestingly, this fix was developed in so called 20% time when company employees can choose any task that seems interesting to them.

Improvements for Filtering for User Picker Custom Fields

It’s not uncommon in a project to add fields with JIRA user selection. This is the case when a User Picker field is added to the View and Edit windows.

Before version 6.2, this field had a significant limitation: the list of users available for selecting couldn’t be restricted in the settings which may come handy, for example, in the following cases:

• there’re a lot of unrelated projects and users in your JIRA (for example, if you’re a large outsourcing company). With the User Picker field added to a project, you want the users to fill it with only those groups\roles that are relevant to the project.
• if your customers as well as your employees can access JIRA, in most scenarios User Picker will be restricted only for employees or customers to avoid filling it with erroneous values.
• in JIRA, if a user is the issue reporter, you can’t remove them from the list of all users. In this case, such users are usually moved to the inactive group, but they remain in the list of users. Ideally, you may want to avoid situations when the field can be filled with not existing users.

Now, the User Picker field has the option User Filtering that restricts a list of available options either to groups or to roles in a project:

It should be noted though, that there was an add-on with this functionality. However, from now it’s available out of the box.

Audit Log

Many companies that use JIRA as an issue tracker or a project management tool have a large number of employees. In these companies, JIRA is usually administered not by a single person, but by a team. This leads to situations when somebody changes something or deletes a custom field and breaks some business process.

There was a growing need in auditing admin’s actions and finally it was implemented. As of now, in audit you can log the following types of actions (the list is incomplete, of course, still it gives you the general idea):

• adding, editing or deleting a wokflow
• adding or deleting a custom field
• adding, editing or deleting users

For every event, you can see various relevant details. For example, if a custom field was created, you can see the time of creating, an IP address of a creator, as well as name and type of the custom field.

By default, the audit log is disabled and you should enable it manually.

Statuses Look

As Atlassian says, the icons with text used earlier as issue statuses went out of date. In a new JIRA, the look of statuses is unified according to Atlassian Design Guidelines.

Miscellaneous

Finally, we should mention the following things implemented in JIRA 6.2:

• now you can search issues by attachment with JQL expressions. For instance, if you need to find all issues without attachments, use the expression attachments IS EMPTY.
• workflow editor is significantly improved. Now you you can edit a workflow for a certain issue type right from the admin panel.

Summing up, the new version is a real step forward. Of course, there’re still some painful drawbacks in JIRA, but nothing is perfect.