How can I restrict a user, so he can see one project only?

[YvonneY]

Companies sometimes have external contractors, who should only see certain projects.

How can the view be restricted?

[YvonneY · Accepted solution]

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 concern
Please 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.

[Ricardo Malias]

That's too much hard, I will need make a PhD in "jira things" to understand that.

[Shahzad Fateh Ali]

I could not see the option for creating new permission scheme in JIRA Cloud. Can you share the link?

[Rakesh Kotian]

Is there any way we can also restrict the same user group from viewing comments

[Jaime Drysdale]

No, I've just created and configured a new permissions scheme (to restrict users to a specific project)... it appears that you can only set whether comments can be added, edited or deleted. There is no setting/permission for who can see them.

[Ivy Clark]

It's possible to restrict who can view comments, when you're creating/editing a comment. We use jira software project type and this is visible when you're editing comments, and you can select roles or groups:

[Rian Mueller]

All of this seems needlessly complicated. This is what I did.

1. Create a contractors usergroup.
2. Set up the external contractors as members of the contractors group, and not the users group.
3. Assign the contractors group to the users project role in the project you (or developers if you wish them to be developers on that project)
4. Assign the JIRA Users global permission to the contractors usergroup so they can log in without being in the users usergroup.

JIRA configuration is a huge pain so I try to keep it as simple as possible.

[John Schultz]

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.

[ethedy]

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!

[Kevin Ramm]

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]

Kevin, you do not want to add the group to the default permission scheme. The point of the above steps is that the project role handles the necessary permissions. This way you can have multiple different external clients with their own projects without allowing them visibility of each others' projects. Follow the steps, unless JIRA changed the way things work in the last year.

[Kevin Ramm]

Thanks Rian. I actually figured this out after reading your steps but now have our permissions setup and they work great!

[Eric Klein]

This was much better as a solution....like most things with Atlasssian, vastly more complicated than it should be....but always happy when you find a simpler solution.

[Astrotek R&D]

It's like some sort of bureaucracy hell

[Victor Santillan]

Sorry to ask but I am new to Jira and I can't find the place where you specify #4 above to assign the JIRA Users global permission to the contractors usergroup. Where is that at? In the config section for specifying the group there is no way to set permissions to the group. In the area where the project is configured under Permissions the settings are the default schema. ? Thanks

[Deleted user]

I'm also blocked at #4. Not sure what that step entails. Could you tell me where to go for that?

[Victor Santillan]

Go to Hamburger menu, Configure, ./ System / Global Permission , Select JIRA USERS from dropdown in ADD PERMISSION section, Select the new group you added from Group, click ADD. This will make it work, basically step #4.

[Bryan Knight]

"Select JIRA USERS from dropdown in ADD PERMISSION section" doesn't exist here. The pulldown is Permission and that contains: browse users, create shared objects, manage group filter subscriptions, and bulk change. Below that is the group. But I do not see "Jira Users" as an option in the top pulldown.

[Nick Verwymeren]

@Brian Knight I'm having the same issue, no JIRA USERS in dropdown. Did you find a solution?

[Bryan Knight]

Yeah I finally did figure it out on my own (probably one of many paths to this resolution). What I did was make groups for each project. Added the people to each group. Copied the system default schema into a new one for each project. Removed jira-users from the browse projects and issues schema section. Added that group to the new schema instead. And as long as there were no projects left using schemas with default jira-users access, the restrictions worked perfectly. New users get setup and you just add them to the group you want them to see a project for. Hope that helps!

[Alicia Pena]

Thank you Rian this was a great help!  For those of you using crowd authentication, don't forget to also login into your crowd server, select applications, jira, groups and add your new group, or they won't be able to login to JIRA until you do.

[Neal Barnett]

For # 4, since the JIRA Users global permission has been removed, try this:

Assign Application Access to the contractors usergroup so they can log in without being in the users usergroup

1. Click on the gear on the upper right while in Jira Administration, and choose Applications
2. Click on Application Access on the left
3. Under Jira Software, click on Add Group, and choose the contractors group

[Max Pavlov]

Neal Barnett, beware, that doing this will add the user to Default Permission Scheme thus providing him/her access to all projects that use the Default Permissions Scheme. 

[Deleted user]

@Bryan Knight this is the solution I was looking at... think it's the best there is.

[Elvis Benkovic]

Doesn´t work for me. Done like described above. But user of this separated group sees all projects. Should I do specific changes to the project Default Permission Schemes of other projects?

[RebeccaM]

I followed all the steps (with the modification for #4 from Neal) but my contractors can still see all projects, I want to limit them to seeing only their project(s).  Any ideas how this can be accomplished?

[Edgar Moss]

I want to know the same thing!

[Mason Foley]

I have followed the steps above as well.  My segregated group can still see all projects.  Something fundamental is being missed it would seem.

[Nic Brough -Adaptavist-]

You've missed out the bit where you have to remove all the stuff that allows access to other projects.

[robmf]

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!

[Bob Ellison]

This is reason 10000 on why the JIRA UI is total garbage, what a joke.

[James Fedor]

Is there a easier guide to restrict users to certain project ??

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 .

[wired00]

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).

• Click User management in top right (click the cog icon) > login as Administrator > click Groups (left menu)
• Add group, self explanatory > Name = restricted to xyz group (or whatever you like)
  
  

2) Create a new permission scheme (Restricted to Project XYZ permission scheme)

• From Administration area > Click Issues > Permission Schemes
• Copy the default scheme as the guide says, > Click "copy" next to "Default Permission Scheme".
• Now this part takes some time. I deleted every single permission, then clicked "add" next to the below items.
  
  
• add > Click "Group" Radio Button > select your group "restricted to project xyz group" etc
  
  • Hint: I middle mouse clicked each item open all at once, first to delete, then to add. Makes it less tedious.
    
    
• Here are the items I Assigned to my group:
  
  • Project Permissions > Browse Project
  • Everything under "Issue permissions" section
  • Comments Permissions > Add Comments
  • Comments Permissions > Delete Own Comments
  • Comments Permissions > Edit Own Comments
  • if using time tracking:
    
    • Time Tracking permissions > Delete Own Worklogs
    • Time Tracking permissions > Edit Own Worklogs
    • Time Tracking permissions > Work On Issues
      
      
• I'm not sure if these are "correct" but it works for me.
  
  

3) Link the permission scheme with project XYZ

• Click Projects > Select your Project (project XYZ) > Click "Administration" at top of screen (Next to overview) > Click Permissions (left menu) > Click Actions > Select Use a Different Scheme
  
  
• Why, do I have to go into the project to do this? It should just be available via the Administration area under project! This took me 5+ minutes to find just now even though I've done it before.
  
  

4) Grant the Global Permission "JIRA users" to the group "restricted to project xyz group" so they will be able to log in.

• Go back to Administration area > Click Cog top right > Click System > Click Global Permissions (left menu)
• Add Permission > Select Permission = JIRA Users, select Group = restricted to project xyz group (etc)
• After this you should see your group appear next to "JIRA Users" just click View users, then invite/add the users as appropriate with your group selected.
  
  

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!

[Robert Nyren]

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.

[Tomas van Rijsse]

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"

[Frederico Borges]

It took a coupke of days but I could set the Permissions right. Thanks

Tomas 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

[Malte Helmhold]

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!

[Andrew Pitts]

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.

[Ramiro Pointis]

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.

[Ramiro Pointis]

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.

[YvonneY]

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.

[YvonneY]

Hello Ramiro,

While this is true it is not the full answer, you will run into the problems described by my in the answer.

[Ramiro Pointis]

I don't understand, you vote down my answer because it's not the full answer?

it is a possible answer, but it is only a different point of view or another solution. The contractors group could be a rol in the project like 'Client'. Or a specific rol called 'Contractors'.

It is possible to change a vote if you press again the arrow that was pressed.

[YvonneY]

Hello Ramiro, I did not intend to vote at all, this happened by mistake. But you might wish to ready answer to see the full scope of the question. I vote you up now because it is not possible to take back a vote, even if it was by mistake. Cheers, Yvonne

[YvonneY]

Hello Ramiro,

I hit the button by mistake only, corrected :)

Thing is that the question is related to OnDemand, there other conditions apply compared to the standalone versions,
so the answer is not wrong, but you won't achieve what you are aiming for.

Cheers,
Yvonne

[Ramiro Pointis]

OK, yes, I had a few problems with that because I have the Standalone Version and I don't know very much about the On Demand version.

[Joe Pitt]

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

[Brook Warner]

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.

[Tobias]

I ask myself the same question!

[bint_IT]

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?

[Carlos Delgado]

I'm still struggling to accomplish the number one answer.

[Nic Brough -Adaptavist-]

Closing this thread as it has become way too long and people are posting without reading the right answer above.

[Maxime]

I wrote an article about it:

https://focusrealm.com/2019/03/25/discovering-jira-user-management/

[Jaime Drysdale]

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.

[Ziko Rajabali]

@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.

[Malte Helmhold]

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!

[Carlos Delgado]

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.

[Mark Wiltshire]

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

[Joe Pitt]

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. 

[Hamaad Rehman]

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

[Joe Pitt]

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. 

[YvonneY]

Please keep in mind, this Q&A relates to the OnDemand solution. For Standalone other conditons apply!

[Jo-Anne MacLeod]

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.