Get hands-on training for JIRA Software, Confluence, and more at Atlassian Summit Europe. Register now ›

LogoV-RVB-850x500pxThis is a guest post from Valiantys, a consultancy specialized in the deployment of Atlassian products.

Since being recognized as an Atlassian Expert in 2006, Valiantys has developed an expertise trusted by over 600 clients and is ranked in the Top 5 Atlassian partners worldwide.

Many different types of organizations use JIRA to power their business.  JIRA is a platform of choice because of it’s flexibility to adapt to many different use cases.  Valiantys brings extensibility of JIRA to a new level with the marketplace plugin, nFeed. nFeed enables JIRA administrators to populate custom fields with the power of a database. Let’s dive into a usecase that showcases the flexibilty of nFeed.

Many companies use JIRA to plan and track work. Ideally you might not want your users directly creating issues in your development projects, right? You’d rather manage feedback in one – or several – dedicated projects. There are several options available to you, from a single entry point to one feedback project per product.

Each solution has its pros and cons, but in all cases you’ll require the customer to give additional information. Generally, the more precise the customer demand, the quicker it will be answered by the product team. Knowing at the very beginning what product and what version they’re using will save a lot of time.

Make giving feedback easy

It’s essential to make giving feedback easy.  We only want a single entry point for our users. Let’s build a simple feedback form!

In JIRA, we can use a cascading select list that will show something like this:


Note: We cannot use the standard version picker here because we have a separate JIRA project for feedback.  The version picker only shows versions for the current JIRA project.

Ok, now it is working, but this isn’t exactly what we expected:

  • First, you will need to maintain these lists manually. E.g., you’ll need to update the options list every time a new version or a new product is released.
  • Second, there is no relation between the two fields (Product and Version). The customer is given all the versions of all the products regardless of the selected product.

But I don’t want to do the job twice!

Of course you do not want to update the versions in the field options any time there is a new product version – You already have this information in JIRA.

To solve this issue, we will use a Valiantys add-on called nFeed (available on the Atlassian Marketplace) which is able to query the database directly.  Knowing how a SQL query looks like will help!

Now, let’s go back to our feedback project configuration. Instead of creating two select lists, we create two custom fields of type nFeed, one for the products and one for the versions.


The add-on can extract data from a database (local or remote) and display it to the user just like a select list. What we will do is read projects and versions lists directly from the database.

In the add-on administration page, you already have a connection to your local JIRA database (the default datasource connector below):

Tip: If your development projects are located on another JIRA instance, it is possible to create a connection to that database. You can refer to the plugin documentation for more information.

Now go to the Configuration tab and create a new configuration for your product custom field:

At first, make sure to select the datasource in the General parameters:

Go to the Field input tab. This is easier than it seems:

Set the Display mode to Select list and in the Query field, enter the following:

SELECT pname, id FROM project

The Query and Key fields require a bit more explanation. The query will contain the SQL query to get the data from the database. In our case, we need the projects list. In JIRA database, project is the table where JIRA stores the projects list. We want to get the project name (pname) and id.

The Key input represents the index of the unique key in this query result. This is also what will be stored in our custom field. The pname has index ‘0’ and the id has index “1”. In our case, we want the id column to be our key so we need to input “1” here. We’ll use this later.

Advanced project filtering

You will certainly need to reduce the number of projects returned by this query. Indeed, this returns all the projects on JIRA, including those not related to your products. For advance users, if, for example, your products project are in a category named Product, you could use this query to filter:

SELECT project.pname, FROM project, projectcategory, nodeassociation WHERE projectcategory.cname = ‘Product’ AND nodeassociation.sink_node_id = AND nodeassociation.source_node_id = AND nodeassociation.source_node_entity = ‘Project’ AND nodeassociation.sink_node_entity = ‘ProjectCategory’

Now save this configuration and do exactly the same for the version field (do not forget to set the datasource connector):

 In this case, the query is:

SELECT vname, id FROM projectversion


This looks quite the same as standard select lists, but values are populated from the database directly. If a new version is created in a project, it will be listed automatically.

How do I filter the versions ?

Great, now that products names and versions are populated automatically, how do you filter your versions depending on the selected product ?

This can be easily achieved with a little change in your version query. Just update your version query like this:

SELECT vname, id FROM projectversion WHERE project = $issue.Product

The ‘$issue.Product’ is identified as a variable and will be replaced with the value of the Product custom field before evaluation. Do you remember the id and key = 1 in the Product field configuration? This is where we need the project ID.

Now the versions list is restricted by the selected product:

A bit further

Any useful information given to the product team can greatly improve your team speed. This was a simple example using the local database, but with nFeed it is also possible to use a remote database (not only a JIRA database) to extract user information from your LDAP server or from the REST API provided by your CRM.

In our examples, we only displayed what was selected, but you can also display detailed information from the selected entity (user phone and location, customer history, etc.) .

Interested in taking JIRA’s custom fields to the next level?

Try nFeed for free


Fresh ideas, announcements, and inspiration for your team, delivered weekly.

Subscribe now

Fresh ideas, announcements, and inspiration for your team, delivered weekly.

Subscribe now