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.
Table of Contents
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:
«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.
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.
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.