Tune-up JIRA, avoid duplicates, and efficiently manage your IT support projects

This post is written by Nicolas Simon, Support Product Engineer at Valiantys.

Nicolas SIMON is a french Support Product Engineer at Valiantys based in Montreal. After a few years in Toulouse as a software developer, he decided to move to the exciting city of Montreal. When he is not helping Valiantys Software customers use their add-ons to the fullest, you can find him playing a wide range of music instruments and trying new dishes in Montreal restaurants.

Since 2010, Valiantys Software has enhanced the Atlassian platform with amazing add-ons that help you leverage data and smoothen end-user experience. With nFeed, Exocet and Spreadsheets, we’ve helped over 1,200 enterprises extend their JIRA and Confluence capabilities, including Airbus, Apple, BBC, Ingenico, Nike, Oracle, Walmart and Walt Disney. You can find all of our add-ons on the Atlassian Marketplace.

To find out more, visit www.software.valiantys.com

When running an IT support project on JIRA, users often go directly to the issue-creation process to get help from the support team. They are not always aware that the questions they ask or the malfunctions they raise may have already been reported in another issue. In this situation the support team ends up managing a substantial amount of duplicate JIRA issues, which is not optimal for the platform’s performance. In this blog, we’re going to showcase a possible solution to lower the number of duplicates using nFeed.

The nFeed for JIRA add-on helps to build a read-only field displayed at creation to suggest similar issues to users. The desired behavior is the following:

• The user opens the creation page.
• The user starts typing a summary.
• While typing, the nFeed field — displayed right under the summary — requests a search of the JIRA database for issues that contain a similar summary. In order to enrich the example, we’ll assume that we also want the retrieved issue to be in the same project, and the same issue type as the user selected.
• If the user thinks a suggested issue is relevant, they are encouraged to click on it to check whether the issue addresses the problem.
• If no similar issue is retrieved, or if the suggested issues are not relevant, then the user will open their own issue, lowering the risk of duplicate JIRA issues.

The first step obviously consists of creating a new field. This is probably the easiest step, as the field only has to fit the following rules:

• Simple nFeed field
• Set in the creation screen only

Once complete, we will now configure the way nFeed will retrieve the values for this field. It will build a list of possible similar issues, collected from information stored in the JIRA local database, so configuring the JIRA local data source in the nFeed configuration panel is a prerequisite.

The user isn’t required to select any data in the field — this is why it will be a read-only nFeed field.

Last but not least, the field might suggest more than one issue, therefore we want it to be able to store multiple values. However, we will limit the results’ number to ten for convenience and performance reasons. The parameter can be set through the Configure button in the Edit Configuration page.

The edit query

nFeed gives you the possibility to use the powerful JQL (JIRA Query Language), which is used to access a list of issues in the integrated JIRA search tool. That is how the edit query will be designed in our example, and it’s also possible to build an SQL query to achieve it. Prior to building the JQL query, make sure the language parameter is set to JQL in the nFeed field configuration page.

The query will need to retrieve issues based on:

• The value the user is typing in the Summary field
• The project on which the user chose to open the issue
• The issue type the user selected

nFeed can build its content from values set in other fields — this is what will be used to design the edit query. nFeed uses a specific velocity syntax to gain the values of various fields. The variables needed for this example are:

• Summary: $issue.summary
• Project: $issue.project
• Issue type: $issue.issuetype

When such velocity variables are used in the edit query, the nFeed field value will depend on all the specified fields’ values, which means the suggested values will not be the same depending on the value the user selects for those fields. For more information about what velocity variables and functions are available in nFeed, please visit our documentation portal. Here the desired query will be designed as follows:

Note the use of the wildcard (*) in the summary constraint, which is used to get even more results. For more information about JQL, please have a look at the Atlassian documentation.

The display template

Now that the field retrieves the desired list of issues, it’s time to set a convenient display pattern. We don’t want only the key to be displayed — it’s much more attractive and integrated if the values show a small warning icon, as well as a link to go directly to the suggested issue. nFeed provides the possibility of using HTML in the Edit Display template. Basically we need two pieces of information to be displayed: the Key and the Summary of the suggested issues. In the display template, nFeed uses the syntax {key} and {summary} to refer to these fields. One example display template would be:

In this example, we use a small warning icon that comes from the Atlassian User Interface (AUI) library.

Try it out!

Ready to try your brand-new nFeed field and to better manage duplicate JIRA issues? This example can obviously be enhanced — it’s now up to you to customise nFeed configurations to fit your needs. Give it a go!

Originally published at Go2Group.