Here a basic overview of the permissions concerned:
* JIRA permission
* Global Permission
* Application specific permissions
Other important things to keep in mind:
* 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.
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.
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.
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
"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.
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!
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
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 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.
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 .
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!
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
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.
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 ??
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.
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?
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 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.
@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?
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.
We're looking for participants for a workshop at Atlassian! We need Jira admins who have interesting custom workflows, issue views, or boards. Think you have a story to sha...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs