nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Permissions by Role / Issue Status

Frank Hanisko

We use Jira to track issues currently, but it is only a list of issues, who is working the issue and when they will be released. This works for internal engineers in our team.

I want to provide the ability for additional users to have limited permissions and different levels of visibility.

I want some engineers to be able to submit issues (bug reports, feature requests)
I want some outside users to be able to see the issue description and original report and release version, but nothing else. These users submit bugs and have an interest in the outcome, but must be kept from seeing what others do (they can see any issue, but not who submitted it or detailed information)

I want developers to be able to make comments or updates to an issue's status which would forward it to me automatically.

I used a different bug tracking software and this was the default behavoir and it worked well.

How do I get started with this?

Thanks

Disclaimer; I am not an Jira global administator. (although I have administration rights for my project) I have used JIRA in other roles, but will be using Jira as a tool in a project I am managing, but need to understand it better to communicate effectively with the administrator. Also, we have an old version 3.13.X enterprise so perhaps an upgrade is in order (but such things must be cost justified)

Accepted answers

EddieW_h8oivr

Although you can separate who can create vs. who can view issues, based on project roles. THe "view" permision is all or nothing (description, assignee, comments, history, etc) based on the "browse project" permission.

Permission to browse projects, use the Issue Navigator and view individual issues (except issues that have been restricted via Issue Security). Users without this permission will not know that the issue exists.

You can add additional restriction to individual tickets using "issue security schemes" https://confluence.atlassian.com/display/JIRA040/Configuring+Issue+Level+Security, but that will not separate out individual fields either.

We do have cases where only the "auditor" role and developer can see a given issue, and no one else. Other cases where the "reporter" can see the issues they submitted, but no one elses. But again, all details of the ticket are visible.

There is an open JIRA for field level permissions, but if i recall it is not something they plan to take on -

https://jira.atlassian.com/browse/JRA-1330

Finally you can certainly received notifications of all comments, but wow - spam overload.

https://confluence.atlassian.com/display/JIRA040/Creating+a+Notification+Scheme

All comments

Nic Brough -Adaptavist-

The permission scheme usage has not really changed much - your 3.13 install has the same concepts and very similar structures to a version 6, at least in terms of permissions.

Jira can certainly do most of what you need in terms of allowing people to do stuff, but you simply won't get the restrictions on seeing stuff. If a user can see an issue, then they can see ALL of it. The history, all the fields, everything that is done to it.

This is deliberate on the part of Atlassian - it encourages people to work openly and visibly. There are plugins and workarounds which can hide parts of the information, but they really are add-ons, they're not part of the core, and most of them have small leaks (e.g. hiding a field from a user works, but it still appears as searchable when they start searching)

For the permissions, there's a question you need to ask your global admins before we can guide you further - how "open" is your Jira? The default distribution has an approach which is, again, open and visible, and it's a right nightmare to unpick it when you need to do any form of restriction. Basically, there's a group of users that "can log in". That group, by default, is "jira users". That's all fine, except that the default setup is to use "jira users" in the permission schemes. The effect there is that as soon as a user can use Jira, they get access to all the projects using "jira users", and it is impossible to lock them out when you need to restrict a project. You need to know if that is the current pattern of usage. If it is, then you're going to need to get them to change it, for every permission scheme.

EddieW_h8oivr

There is an open JIRA for field level permissions, but if i recall it is not something they plan to take on -

https://jira.atlassian.com/browse/JRA-1330

Finally you can certainly received notifications of all comments, but wow - spam overload.

https://confluence.atlassian.com/display/JIRA040/Creating+a+Notification+Scheme

Frank Hanisko

At present it seems quite "open", there are three types of users, administrators, developers and users. Everyone can see everything and do almost everything, but as an administrator, I can manage membership, components and versions. I can't see groups, but I can see users. A "user" can see or do pretty much anything else. A developer can't move or clone, but can do anything else.

We have multiple projects and we do limit users to certain projects. That doesn't help me. I have multiple suppliers and customers on the same project.

I am concerned because if everyone who can view can view everything, then this may be a non-starter. I don't need to encourage openess, I need process control, security and privacy for a critical environment. I want to encourage test engineers to submit issues and I want to be able to share these with vendors, but I can't give one vendor permission to see information that may contain the IP of another. The only way I see around this is to have seperate internal JIRA and for me to manually copy information or move Issues from one to the other.

Nic Brough -Adaptavist-

No, I understand the need to ring-fence projects off, I was just pointing out that you need to establish if you've got a structure that supports it yet (because if your admins have gone with something like the defaults, then you don't and you'll need them to do the work to enable it)

Most of the Jira installs I've looked after have been divided up. It's mostly along business-unit lines, and often they've remained relatively open (Business unit A can *see* what business unit B is doing, but not touch it, beyond issue-linking).

But you can set it up so that Business unit A can only see projects that belong to it, and business unit B can see only B's projects, and then managers can see both, and external users nothing but a single project, and so-on.

You can also do issue-level security (independently of the global permission stuff). That boils down to something like "if you set a security level of "red" on an issue, then only the people who have "red" access rights can see it". Obviously, they have to be able to see the project in the first place, and if you don't set a level, the issue is open to everyone with browse in that project.

Your "vendor" model is even demonstrated in Atlassian's own support Jira. If I log a support call, I can see it. Atlassian can see it. None of the rest of their customers can see it.

The first hurdle you've got here is closing off your "open" access scheme by the sounds of it. But you need to talk to your admins to find out if it really is set up that way. Ask them to look at the "can log in" groups in global permissions, and then how the groups named are used in the permission schemes.

Frank Hanisko

I'll speak to the admins Nick. Your reply makes me think there may be a way.

To be clear, unlike the Altassian support Jira, I want everyone to be able to see issues submitted. What I don't want them to see is who submitted the issue or the data around it. So, if user A submitts an issue that the software crashes when processing a certain XLS file, i want that user to be able to upload the XLS file so I can use it to confirm the bug. That user won't do that if the XLS file can be read by other users. Yet, I want all users to know that there is a problem with XLS files. In that way all users gain from the experience.

Right now, I have an excel spreadsheet which I provide to users. They send me emails and I enter the problems. The only update they get is when I send a new spreadsheet out. Lots of overhead for me. Also, I have to have a seperate JIRA project for each vendor, so more overhead to segregate issues.