Permissions on issue types with nFeed

Posted by

May 5, 2015

Many JIRA users think that the tool is limited regarding the level of permissions. Indeed, it is currently impossible to specify native permissions by issue type. This would come in quite useful in, for example, the “Browse projects” permission. In this case, how do you apply this permission to an issue type, or even better, to certain people in a same project? At a glance, it seems like ‘mission impossible’.

It should come as no surprise then that you may encounter visibility or confidentiality issues. It might even be necessary to restructure one or more JIRA projects in order to segment the content. While you can find several ways to avoid this, most of them will be quite complex to implement and not always an ideal solutions over the long-term.

Let’s see how to fill this void with a quick and simple method that is one of the many possible uses of the nFeed add-on.

Use case

For « Valiantys – Support » project, the « Admin » user has all the rights on the project and can consequently see all the issues. However, we would like to authorise the user “Nicolas” to see only “New feature” type issues and “Jeremie” to see only “Bug” type issues.

Project: Valiantys – Support

Issue types: Bug, Improvement, New Feature, Task

Users: Administrator, Nicolas, Jeremie

Purposes: “Administrator” can see all the issues (already done), “Nicolas” only “New Feature” issues, and “Jeremie only “Bug” issues.


In 4 steps, we will reach our objective.

Step 1 – Create a “nFeed – Users” custom field

We will call it « permission granted to ». Keep a track of its ID because you will need it later (visible in nFeed configuration: 10242 in our case).

Add this new custom field to the screen views for all concerned issue types.

In our case, this is a unique screen for two issue types:

“Generic – OP – Vue SCR”.

2015-01-12 15_19_50-Custom Fields - Your Company JIRA

Step 2 – Create a nFeed configuration for this field

“General parameters” tab:

2015-01-12 15_21_50-nFeed

“Field input” tab:

For this part, issue type and users ID will be necessary. In our example:

  • Bug : ID = 1
  • New feature : ID = 2
  • Nicolas : ID = 10207
  • Jeremie : ID = 10208
To get your issue type ID, you need to go to “Administration” > “Issues” > “Issue Types”, you can spot the ID in the URL of the button “Modify” of each type.

For users, you must go on the database. The table is called “cwd_user”. You may also make a request using only “user_name”, but this is not the ideal solution.

2015-01-12 15_23_51-nFeed

The request is particularly interesting here. For each issue type, please select the desired user.

#if ($ select user_name from cwd_user where id=10207
#elseif ($ select user_name from cwd_user where id=10208
Remember to tick Auto-select unique result. To do so, click on “Configure” to access advanced options:

2015-01-12 15_25_00-nFeed

Then, save the configuration.

Step 3 – Automatically set the nFeed field value

To do this, you will have to use a publishing feature. The “Create Issue” workflow transitions associated to issue types will be impacted. On these, you must add a publication feature provided by nFeed.

The one we’ll look at is “Apply a value to a nFeed field”. In the feature parameter, indicate the ID previously quoted in order to identify our “Permission given to” nFeed field.

2015-01-12 15_26_45-Transition_ Create Issue - Your Company JIRA

This way, everytime a “New feature” or “Bug” type issue will be created, the nFeed field displayed on the screen view will dynamically take the value of the person concerned, without needing to display it on the creation screen.

In our case, the workflow is identical for the two issue types, so you only have to do this once.

Step 4 – Use the nFeed field to affect permissions

Be sure to assign the “Browse projects” permission to the “Permission granted to” field in the authorisation system used by “Valiantys – support” project.

2015-01-12 15_28_17-Add New Permission - Your Company JIRA

This way, the user will only be allowed to see the project issues with the issue type defined for him.

Using this field is also possible on other permissions.


The “admin” user has created two issues, one of each type:

2015-01-12 15_31_03-Issue Navigator - Your Company JIRA

When the user “Nicolas” logs in, he can only see “New feature” type issues.

2015-01-12 15_32_33-Issue Navigator - Your Company JIRA

On the opposite, the user “Jeremie” can only see “Bug” type issues :

2015-01-12 15_33_15-Issue Navigator - Your Company JIRA

And here we are ! With nFeed, you can then easily improve your JIRA experience by setting more accurate permissions that really fit your need. And this is one example among so many!

One step further

Here we studied a simple case, in which we use a “nFeed – Users” field to grant a permission to a particular user depending on the context (here: issue types). However, we can also extend this tip to groups. To do so, we must use a “nFeed” field type (called “Permission granted to (group)” in the following example).

The only difference lays in the request. Instead of fetching a user, the field will fetch a group.

To get groups ID, we must search into the database. The table is called “cwd_group”. JIRA groups ID by default:

  • jira-administrators: ID = 10000
  • jira-developers: ID = 10001
  • jira-users: ID = 10002
#if ($ select group_name from cwd_group where id=10002
#elseif ($ select group_name from cwd_group where id=10001
As we did previously, we must add this new field in the authorisation system:

2015-01-12 15_35_25-Add New Permission - Your Company JIRA

This time, the field fetches in “Group Custom Fied Value” and not “User Custom Field Value”.

As a result, “New feature” type issue will be visible by everyone, while “Bug” type issue will only be visible by devs.


Now you know how to dynamically use a nFeed field on a permission. This tip will avoid you much pain, i.e. segmenting the content of a JIRA project, and will then help you save some precious time! Would you like to see it for yourself? You can try nFeed for free and make up your own mind about it.