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!
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 ??
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?
Everything below is tested on Ubuntu 17.10. I prefer to use Jira in a docker container because: 1. I can install Jira with a couple of commands. 2. I can start and stop Jira just by starting and s...
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
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot