Companies sometimes have external contractors, who should only see certain projects.
How can the view be restricted?
Here a basic overview of the permissions concerned:
* JIRA permission
* Global Permission
* Application specific permissions
Other important things to keep in mind:
* Groups
* Permissions fed by the group, see Project Roles
Have a look at your permission schemes. Most likely your projects will be linked to one permission scheme only, the default permission scheme.
While this is great to get started it is not the best approach if you intend to restrict permissions for one user and one project. When you check the permission on the permission scheme you will see, that the group "users" inherits many permissions from the default. But of course you cannot just revoke those, other users might be dependent on that, especially as this is the minimum requirement to log in to the application.
Here a step by step plan to follow:
* Create a new group, let's say "restricted to project xyz group" and add the user of concernPlease use only lower case letters for naming groups!
* Create a new permission scheme, let's call it "Restricted to Project XYZ permission scheme" by copying the default. Now revoke all rights that the project role users or the group users has.
(To make life easier in future you may wish to save a blank scheme, it's a lot of clicks otherwise)
* Modify the "Restricted to Project XYZ permission scheme", in detail, grant the appropriate permission to "Restricted to Project XYZ Group"
* Now link the permission scheme with project XYZ
* Grant the Globel Permission "JIRA users" to the group "restricted to project xyz group" so they will be able to log in.
So far so good, but we are not quite there yet. Check next the Global permissions and ensure, that the user does not inherit any permissions there via the group "users".
Next step: Check your application permissions!
For example, go to SVN. Here you will see that by default users have the right to view source code. This could be fatal for your business if the external user is not supposed to see it! Revoke this permission from the group user, but don't forget to check if you would revoke the permission from the wrong person/group.
By default developers and administrators can commit, which includes the right to view the code, so as long as your developers are in this group they will be fine to view the code.
Now you need to check all other applications that you might have bundled in your OnDemand instance.
Hi Yvonne, in the project administration section you can configure the permissions scheme. The 'Browser Project' permission it is the one that determinates who can see the project.
You can have the permissions for different roles and the in the 'People tab' of project administration section you can select the users that would be in the specific roles.
Hello Ramiro,
While this appears OK you will run into the problems described by me in the answer because it is related to an OnDemadn instance.
While this is true it is not the full answer, you will run into the problems described by my in the answer.
My approach would be:
Create a contractors group
Put users into the group
Pull up the permission scheme for the project in qestion.
give contractors group the appropriate permissions
ensure that the jira-users group is not in the permission scheme at all (it is VERY bad practice to use this group for permissions anyhow).
ensure that any roles that the contractor may be in does not have jira-users in it as well.
When the contractor is done, just remove the user from the jira-users group. When (if) they come back put them back in the one group and all of their access is still there. Note, never delete the user. If you don't want him anywhere then create a "inactive users" group and remove them from all groups, and put in the inactive users group. Making sure that the inactive users group is never used in any permission scheme.
Please keep in mind, this Q&A relates to the OnDemand solution. For Standalone other conditons apply!
Hi there, I am a newbie to JIRA so please excuse me.
I tried the above to fullfill my scenario.
I want to restrict certian users, to certain products.
i.e. I am creating a number of projects and these are only seen byt their respective clients.
I did the above, but then my admin user then couldn't see the project I has switched the defult permissions on.
I obviously did something wrong, but I am very confused.
I did the following
a) created new user 'userx' where I only want them to see 1 project
b) created new Group - 'restrict to project x'
c) copied default permissions - 'estrict to project x group'
d) then edited this permission so that where it read previous User (group / or role) switched with my new restirct to project x group.
e) Then assigned this new persmission schema to the project x
My test user cannot see anything when logged in, and my administrator account now cannot see the project x
???
Is there a easier guide to restrict users to certain project ??
many thanks
Mark
I would like to see this too, the documentation for Jira could use an upgrade too. For instance looking at the instructions above It took me 15 minutes to find the area to add a new permission scheme. For those unable to find it it's here /admin/ViewPermissionSchemes.jspa .
Does the level of complexity involved here not worry people?
This kind of activity is not hard on other similar applications. Don't get me wrong Jira is getting better in leaps and bounds - But this is an example of an area that is overly complex for little benifit, bring in the UX designers!
I'm still struggling to accomplish the number one answer.
I somewhat disagree with the top method posted. Frankly, the schemes that are in place are simply default scheme. I created my own groups, schemes, etc. and found this to be a somewhat simple process.
@robmf I don't think the level of complexity is worrisome. Jira is very similar to many other defect tracking systems in this respect.
All of this seems needlessly complicated. This is what I did.
JIRA configuration is a huge pain so I try to keep it as simple as possible.
Thanks Rian! I had been meaning to add this to my JIRA installation so an external partner could only see the project he was working on and not all of our JIRA projects. This works great and is much simpler than some of the other options I had previously researched.
I agree with the previous comments about the complexity. The user permissions in Jira are far too complex. This must be a common need and after trying a couple of approaches have not been able to get it to work to my satisfaction.
Jira permissions are hell. I'm not quite new to ERP Systems and stuff like that. So Atlassian rethink your program about that, it's a 100% no go for a program you must pay $1800 exceeding 10 collaborators!
This is reason 10000 on why the JIRA UI is total garbage, what a joke.
Hi Rian! Your solution works OK for me. THANKS I'm with you: JIRA config is too complicated. Perhaps it could have some common actions more intuitive and let the "fine grain" to the experts (I'm using JIRA to teach and very simple projects) Best regards!
I found the problem with JIRA permissions is that things are strewn all over the system. I had the most frustration trying to find what areas the guides above alluded to. Things really need tidying up.
So, here is a guide detailing where to find each section required for security permission setup:
(In order of the main guide above)
1) Create a new group (restricted to project xyz group).
2) Create a new permission scheme (Restricted to Project XYZ permission scheme)
3) Link the permission scheme with project XYZ
4) Grant the Global Permission "JIRA users" to the group "restricted to project xyz group" so they will be able to log in.
That's all for now, I hope it includes everything, its all I could remember. Hopefully it saves someone else from the suffering i went through!
well feel the love man... this is what i had tentatively arrived at after an hour of deep thought - but I could not put it into words; appreciate your help.
Does this group need to be added to the default permission scheme? We have separate external clients that we need to allow access but cannot have them see each others projects.
@Rian Mueller I like your approach best, nice and clean.
While I agree with the complexity of permissions that all have previously mentioned, I absolutely love the power that JIRA provides in my day-to-day usage. I'm glad Atlassian focuses on tackling the problems that plague my gears, hackers n hustlers rather than the ones that plague me (ops manager). They are the ones getting the work done that ultimately gets us all paid, and the more effective they are the better off the company is. JIRA streamlines what we need for day-to-day workflow, control and reporting of our ops (including quality management, product management, project management, risk management, training, and development). I'm happy to trade all of that for gaps in the permissions UX.
I have a some what similar need, and for this found this thread.
It is not about giving acces or avoiding creation of issues to certain users. It's true it is somewhat complex, but I think I wuold not have managed it with a less mighty setup. So it seems not to complex but just mighty.
I searched, for a quite long while, to hide acess to projectinformation not need for certain users not invoved in a given project. Ie. to restrict the list of projects displayed by "show all projects" to the projects realy relevant for the given user. By this, also hiding certain information as: planed and past releases or components, not nesessarly thought to be spread to eg. customers.
After some thinking and serching, I got unfortunately the conviction, that this might not yet be possible, and be some subject for extensioon of the "projectright" section of the permission scheme. In the sense of "Show Project-Metadata" and "List Project". Hiding those informations from the project menue.
Does anyone else think this useful or am I the only one searching for this?
Or prehaps some answers how to do, if my finding would be wrong/incomplet?
Thanks for the in-depth explanation. Only step 4 didn't work for me, in the Cloud Jira there is no permission called "Jira users"
It took a coupke of days but I could set the Permissions right. ThanksTomas in the JIRA Update instead of JIRA Users you need to:
Go to User Managment;
Go to Application Access;
Grant the designated user access to JIRA Software.
That's it
Is there any more updates on this? I'm still struggling with the OP and even after days of reading around the forums and various open tickets, I still can't get this to function.
That's too much hard, I will need make a PhD in "jira things" to understand that.
I ask myself the same question!
I think many of you are making it more complex than needed.
JIRA works by GRANTING access. You can't restrict access. By default it grants access to the group used to logon (used to be jira-users but may be different on your version). This is probably where you're getting the access from and the basic problem with out of the box JIRA permissions
1. The FIRST thing you need to do to get control is to remove any groups with logon privileges from the permission scheme unless you absolutely want everyone to have that permission.
2. Setup user roles for the various functions like, tester, QA, Browse Only, etc. Then you can create one permission scheme to cover almost all projects.
3. The project admin controls which users are put in the roles. This may be a big effort to switch to, but it will payoff down the road by making it easy to control
I could not see the option for creating new permission scheme in JIRA Cloud. Can you share the link?
Is there any way we can also restrict the same user group from viewing comments
Again, YOU CAN'T RESTRICT ACCESS, you GRANT access. You need to remove the logon groups from the permission schemes. The best solution for granularity is using project roles. With planning you can have 1 permission scheme giving roles access and the project admins can assign users to the roles they want to use. Project roles are universal, but not every project needs to use them.
Hi Joe,
In this scenario at what level would you be able to grant access to only x and y projects to the role 'vendor' for example but not grant access to project z? As far as i can tell its a 1-2-1 relationship between a project and a permission scheme and im yet to work out how to then manage the roles so that access is granted to only specific projects?
Many thanks
The project lead would add the user to whatever role they need to be in to work their project. Project roles are on a project by project basis so adding a user to a role in project x doesn't give them access to any other project. By using project roles the project admin controls access and doesn't have to wait for the JIRA admin to add people to groups. I have three main roles.
1. User - I give them every permission needed to work an issue in the project;
2. Browse - Only browse permission. Usually for managers. They can look and run reports but not update anything
3. Watcher - Only browse permission, but I also add them to the notification scheme for major events in the workflow. I added this are the request of managers that wanted to know when issues passed certain milestones.
Then I use other roles to put conditions on workflow transitions.
I set it up as per the the instructions from Yvonne and it wasn't that complicated. The explanations given are a little simplistic, and do get you thinking about where the options are hidden (within the huge complex thing that is the Jira menu system). I find the easiest way to find things is to search for them using the Search Jira Admin option on the top right of the admin pages. It's way easier than remembering where they are hidden.
Is Jira needlessly complicated to set up?
Well it's certainly complicated, but needlessly... probably not.
I wrote an article about it:
https://focusrealm.com/2019/03/25/discovering-jira-user-management/
Closing this thread as it has become way too long and people are posting without reading the right answer above.
It looks like you're new here. Sign in or register to get started.
