Atlassian JIRA 6.2: Be better than yesterday

Today Atlassian JIRA is one of the most famous and popular bug trackers. In addition, a number of companies around the world use JIRA not only as a bug tracker, but also as a project management system. JIRA is versatile enough to solve a large number of seemingly unrelated tasks, and it is quite simply expanding through the development of additional plug-ins.

Every time, Atlassian users expect the next big release of JIRA, realizing that it cannot be worse than the previous one. Therefore, from JIRA 6.2, the release of which was officially held on February 25, expect only positive impressions.
')
In this article we will try to understand what is new for us in the new version of JIRA.

New view on integration with Development Tools

Many users love JIRA for the ability to integrate with it and other tools for developers developed in Atlassian:

• Stash - the Git repository management system that you host
• Bamboo - continuous integration system
• Bitbucket - Git and Mercurial repository management system
• Crucible is a tool for code review.

The new version of JIRA rethinks the approach to integrating tools for developers. Now each application has a Development section, which is the starting point for developers and product managers. The information presented in the section allows us to understand what has already been done on the current task and what remains to be done.


Directly from JIRA, you can see a list of branches, commits, or pull requests associated with this application in your Stash:


Or, for example, you can quickly see the history of the builds and deployments that Bamboo compiles:


In addition, right from JIRA you can branch and start developing new functionality.

"Remember your Creator"

One of the most long-standing problems in JIRA was the inability to look at the application for the name of the user who is actually the author of this application. Of course, there is a Reporter field, but when using it you should always remember the following points:

• the field is optional and in the general case it may not be on the screen viewing the application
• the field is editable and its value can be changed at any time.

As a solution to this problem, the most simple approach to implementation was chosen: in the history of the application, an entry is stored about who is the author of the application:


An interesting feature related to this task is that it was done in the so-called 20% of the time , when employees of the company can choose any task of interest at their discretion.

Improvements in the custom field of user choice

Quite often, you have to deal with a situation where projects need to add custom fields in which you need to select JIRA users. For such a case, there is a custom field of type User Picker , which can be added to the viewing and editing screens.

Before the release of version 6.2, this field had a significant limitation: at the settings level it was impossible to limit the list of users who could be present in this field. Such a need may be necessary, for example, in the following cases:

• There are many projects and many users in your JIRA that are not related to each other (for example, you are a large outsourcing company). Using the User Picker field in a particular project you want to simplify the process of filling it with users only by the group / role that are directly related to the project.
• If both customers and employees of the company have access to your JIRA, then in most scenarios in the User Picker field you will want to limit the selection only to company employees or only customers, in order to avoid any mistake when filling in the field.
• in JIRA, if the user is the author of the application, he will not be able to remove it from the list of all users. In this case, usually such users are transferred to the “inactive” group, but they still remain visible in the list of users. Ideally, I would like to avoid a situation where non-existent users can be entered in the field.

Now the User Picker field in its settings has the User Filtering option, which limits the list of available options either by user groups or roles in projects.


It is worth noting that previously a similar functionality was implemented by a separate plugin for JIRA , but from today, this functionality is available out of the box.

Audit

A number of companies that use JIRA as a bug tracker or project management tool have a large number of users. In such companies, as a rule, JIRA is administered not by one person, but by several. And sometimes there are situations when someone changing something in the workflow or deleting a custom field could break this or that built-up business process.

In JIRA, the necessity of auditing administrator actions has long been brewing and, finally, this possibility has appeared. At the moment, the following events are logged in the audit (the list of events is, of course, incomplete, but it rather clearly indicates the nature of the events):

• add, edit or delete workflow
• add or remove custom field
• add, edit or delete users

In each record of the event, you can see the various details that characterize the action. For example, if a custom field was created, then you can see the time when it was created, the IP address of the user who created it, as well as the name and type of the custom field.


By default, auditing is disabled and needs to be enabled independently.

Appearance of statuses

Atlassian argues that the icons with signatures that were previously used as application statuses are morally obsolete. Now in the new JIRA the appearance of the statuses is strictly unified, which corresponds to the Atlassian Design Guidelines .

Other moments

And finally, it is worth mentioning the following points, which are included in the JIRA 6.2 release:

• Added the ability to use JQL expressions to search for applications by the presence or absence of attachments. For example, if applications without attachments are needed, then we use the expression “attachments IS EMPTY”.
• implemented significant improvements in the workflow editor. Now, directly from the administrative panel of the project, you can start editing workflows for a specific type of application.

In conclusion, I would like to express, perhaps, the general idea that it has become nevertheless better than it was before. Of course, there are still moments in JIRA that do not satisfy everyone, but it’s worth remembering that there are no perfect tools.