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.
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.
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.
“Generic – OP – Vue SCR”.
Step 2 – Create a nFeed configuration for this field
“General parameters” tab:
“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
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.
The request is particularly interesting here. For each issue type, please select the desired user.
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.
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.
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.
This way, the user will only be allowed to see the project issues with the issue type defined for him.
The “admin” user has created two issues, one of each type:
When the user “Nicolas” logs in, he can only see “New feature” type issues.
On the opposite, the user “Jeremie” can only see “Bug” type issues :
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.
- jira-administrators: ID = 10000
- jira-developers: ID = 10001
- jira-users: ID = 10002
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.