I am very new to this Jira stuff. I've been asked to create a Project and restrict it so that only certain users have access to the project. Managing permisssions doesn't seem to be a straight forward process.
What are the specific steps required to make sure that only users/developers associated with the project can see and modify items in the project?
I went to the project, clicked on that little browse drop down, selected Space Admin, clicked on Permisssions under Security, removed 'users' under groups (I think) and then added the individual users who should have access to the project. I then went to another user, who is not associated with the project, and he was able to access it, even though he is not in the permissions list.
I also believe that managing permissions doesn't seem to be a straight forward process. I'd recommend you to take a look at https://confluence.atlassian.com/display/AOD/Managing+project+visibility
You will need to make sure that you have set your permission scheme to use roles (if that is the way that you are going). Apply your permission scheme to your project(s). Then on your project you will need to click on the "People" tab, and assign the users to the appropriate role.
Note, you should confirm that you do not use jira-users in any permission scheme, or in any roles. The group jira-user should only be used to define who can or can't log into the system.
And if I was a brain surgeon, brain surgery would be easy. ;-)
So, I think I just figured out how to create a group.
Now I need to figure out how to create a permissions scheme.
Somehow associate the group with the scheme.
I don't see anything in our system named jira-users.
it is more clean to use the groups than configure permission directly with users (it's my opinion).
You have to do all the actions below in admin space (link up left)
to create a group -> menu users (ver5.1) or menu "users and groups section" (ver4.4), after that you can assign the good groups in the good roles. For that, choose your project and in the section permissions you have the system by default normally. Click on it and change the permission. When you are in the permission system, to change it, you can do it with the combo "actions" -> "edit permissions" or "use a different scheme". But for your need about visibility you don't need, normally, to change the system permissions. You control that with the assignment groups in roles. After many tests you will understand the philosophy :-)
Ok, I'm in the project in the Administration page that has a few tabs under Administration: General, Issues, Wiki, Source, and Reviews. Under that is the project name and several items under that: Issues Types, Workflows, Screens, People, Versions, Components, Permissions, etc.
Under Permissions the scheme is listed as Default Permission Scheme. If I click on that I go to a page that has a lot of trivial permissions listed. I see the actions button. It has the edit permissions or use a different scheme. If I click on edit, all of those trivial permssions items can be deleted or, apparently added to. I don't want to go through the painstaking process of editing all of those little permissions items. Well, and besides, once I drill down into there, it doesn't appear that thos permissions are specifically related to the project in question.
If I go back and try use a different scheme, I have a drop down box that shows 4 available schemes and none of those are specific to the project. I see no option to create a new permisssions scheme that I can use for this specific project.
Why can't it be simple??? Here is my project... Here are the users I want to access it...
Permissions and roles and schemes makes my head spin. Maybe we need to hire a full time Atlassian Sorter Outer person. ;-)
Sorry about the sarcasm. I just have so much to do and this Jira thing, that was laid on my table, is taking up a lot of time going around in circles.
I discovered from a document that somebody here created in the past that I have to go to Administration, Issues, Misc. Schemes, Permisssions Schemes. From there the instructions were to copy one of the schemes, rename it, edit all the permission items in there to delete the groups that were there and add the group I created. I didn't see the option to add a new scheme. And then, of course, I would not have known about doing the shift clicking and editing part.
I appreciate the replies. At least they helped me to know I was on the right track. Also, doing some googling and looking around I see that I am not the only one who is confused about the permissions part of all this conglomeration of Atlassian stuff.
Now, also, I am not convinced yet that this new group and this new persmission scheme willl keep unauthorized users from seeing whats going on in this particular project. I guess that will be seen as we go forward.
Edit: Oh, and I see that my winky smilies didn't help to minimize the sarcasm a bit. ;-)
Do you have the option to create testing accounts? (Temporarily if you have license limits)
They can be really helpful when you're testing permissions. Don't actually do anything with them other than log in and look around the projects you're working with of course.
One other thing about permissions - don't be scared to play. Create new or copied schemes and work with them, keeping the originals. Permission schemes can be swapped on each project in a fraction of a second and take effect immediately. So if you get something wrong, then it's a doddle to put back the old working scheme.
ok remember ... don't touch on the permission before the rights are good. Make tests without changing permissions.
For that, You have to configure the groups and the assignment in projects roles.
And after that you will change the permissions.
i suggest you to use the default permission system and when the rights are configured (with groups and roles) you will have to copy the permission system and configure it. Copying scheme, renaming and configuring the copy is "the" good practice.
Thanks for all the input. I'll use this thread as I learn more about what I am doing.
And yes, I can create test accounts, etc.
Unfortunately, so far, I don't know what this means: ". . . don't touch on the permission before the rights are good." And I don't yet know much about user roles in specific projects. I see some links for project roles. I'll have to get in there and figure it out.
My main concern is my 2 new domain controllers are just sitting in boxes in the server room while I try to figure out this Jira stuff.... :-D
I think Jerome means "do not apply a scheme to your project until you are sure it is correct"
I keep a "test" project in my Live systems, simply so I can test this sort of stuff. Mess with a copy of your scheme, apply it to the test project, test it with the test accounts, and only then, apply it to the real live projects (actually, that's technically a lie, I've been doing this for so long, I don't need a test project for permission checking, but I still use it for checking stuff I'm less familiar with, and showing other Jira admins around)
ok it was not understandable, sorry
Your need is : control the visibility of a project. You have different users and you don't want they see all the projects. It's what i understand.
when i say "don't touch.. are goods", i try to focus your mind on this fact. You don't need to configure the permission system for your need. You just have to create groups and assign groups in the good roles on the project. That's all.
Thanks again for the input. I see what you're saying. And I did create a group with only the users who should have access to this project and created a new permisssions scheme that includes that group and I have assigned that permission scheme to the project. (I think.) (of course, it would still be nice to just go to a project page, click on a users link, select the authorized users, and click OK.)
I'm sure there is some other tweaking to do with the roles but that's going to have to wait until after this upcoming 3 day holiday weekend!
I find it more simple to start with groups. Once you are happy with using groups in permission schemes (and notification schemes and so-on), then you can move on to roles.
Roles are nicer than groups because
Example. I have 2 projects, ABC and XYZ. I have users Alice, Bob and Charlie. I want Alice to see project ABC, Bob to see XYZ and Charlie to see both
If I only use groups, then I create two groups - groupABC and groupXYZ. I create two permission schemes psABC and psXYZ. psABC says "groupABC can browse" and psXYZ says "groupXYZ can browse". I set project ABC to have psABC and project XYZ to have psXYZ. Finally, I put Alice and Charlie in groupABC and Bob and Charlie into groupXYZ. I then have to maintain the groups as users move around, and I've got two permission schemes that might have to be hacked separately if things change.
With Roles, I set up a permission scheme that says "role X can browse" and use it in both projects. Then I ask the project owners of ABC to add Alice and Charlie to role X, and the project owners of XYZ to add Bob and Charlie to role X. Then I leave them to it.
Groups still have many uses, and a lot of power, but in large Jira installations, they become an utter pigs ear, and either need to be replaced by the use of roles, or delegated to an HR function outside Jira somehow (LDAP/Crowd etc)
It's a point of view but it's not mine. :-) With Your solution you have to configure a scheme permisssion by project therefor you have more setting to do, and if you have a lot of projects, i wish you... good luck. However, i am agree with you, to take in hand Jira it may be more convenient.
Ok, i complete my answer "roles oriented" and i invite you to do tests to compare. Play with groups and roles assignment.
To assign a group to the "users" roles of the project. Go in admin space, choose your project. When you are on the summary tab, you have a link "view project roles" (up and right ) in the "people" section. Now you have a little tab with 3 columns, "project roles", "users" and "groups". Click in the third column corresponding at "Users" project role and assign your group. It's simple and there is nothing to do more. With this method you can very easily control "who" can see "what".
Just be careful with one thing. Verify your groups are assigned in the global permission "Jira-users", if yiu do not, log in will be impossible. For that, menu "users" and click on "globals permissions", you will see "Jira users" ...
Thanks again for the replies. It takes me about 20 clicks to find any particular page I have seen in the past. I was finally able to go back and find that Administration page that has a People section and found the View Project Roles link. Under Project Roles there is a row for Administrators, Developers, and Users. Last week I somehow managed to get the project lead into the Administartor row and the 6 authorized employees into the Developers row, and I just now added the group, that includes these 6 people, into the Users row. It seems like a lot of redundant overkill, but as long as this restricts the project to just these people, all will be good.
Now I have discoverd a page that has groups in it. I see the group I created in there, but it has my new project permision scheme and the default permission scheme listed under permission schemes. I see no way to take the Default Permission Scheme out of that list. However, any other random page I find that shows the project and anything about permissions does not seem to associate the Default Permission Scheme.
The link has our company jira url with .../secure/admin/user/GroupBrowser.jspa on the end.
It's really nowhere near as complex as that.
A permission scheme defines who can see and do things in a project that uses it.
A group is a batch of users, which you can use in schemes.
As an administrator, you can create and delete groups, add and remove users from groups, add and remove permission schemes, and associate those schemes with projects.
That's about it.
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
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot