How do I assign certain users to certain projects?

[Bruce Edmiston]

Apologies for asking this question, I am new to Jira Admin and the previous responses that I have found in the main seem to rely on a level of knowledge of Jiras taxonomy and where to go within the UI to carry out various actions

I am really looking for step by step response 'cos "I know nothing"

I have 2 projects (I have managed to create these !)  I have 3 sets of users - when I create the user / ask them to join I want to restrict what projects those users can see.

Set of users (A) need to see Project (1)

Set of users (B) need to see Project (2)

Set of users (C) need to see Project (1) and Project (2).

Having read prior questions / responses on this subject, I get that the Jira default is 'see everything' and therefore if you want to restrict you have to set up your own configuration (permissions ? groups ? assignments ?) and revoke the standard ones.  What I havent been able to do is follow / understand the steps that the numerous responses give

Can anyone out their give me a 'dummies guide / step by step instructions to setting up project access for users' ? 

[Joe Pitt]

If you want all the users to have full access to the project (I don't recomment any delete options) I suggest you setup a project role called Full Access and add that to all the permissions, execpt delete, in the permission scheme. Then add the users to that role in the respective project. If you've already setup groups for the projects you can assign the group to the role. DO NOT GIVE THE JIRA-USERS GROUP ANY ACCESS. The Jira-users group is automatically given to every user when they are created so they can logon. The most frequent problem people have when trying to restrice access is that they gave the jira-users group access. Remember, JIRA, and most systems, GRANT access. By default you have none.

[Bruce Edmiston]

Hey Joe - thanks for this, I havent had a chance to follow up on your suggestions but will let you know how I go.

[Bruce Edmiston]

Joe - thanks for your responses but Ive failed !  I am going round in circles trying to work out where to start in terms of creating a group or a role or a permission schema or permissions and whether I need to allocate permissions to roles or groups or projects or projects to groups etc etc.  

I havent found the magic answer in anythimng I have read and remain frustrated.  Do either of you have an 'abc' in terms of which order I should go about creating things ?  It might help me through the myriad of possible options

[Joe Pitt]

Bruce,

I prefer using Roles. It allows the project lead to control access to their project without involving the jira admin.  Here is where I would start. Keep in mind that project roles are universal so you may not use all roles in all projects. 

1. Start with the logical roles you would have in your projects. Such as Developer, Tester, QA, Admin, Team Member, Watching, BrowseOnly, Create, etc. 

2. Copy the default permission scheme (I never mess with the defaults in any scheme) and make all changes there.

3. Then decide what access each of the roles you created should have.  For instance, you may want some folks to be able to create issues and only browse their issues. So you give them the project role create permission and add 'reporter' to the browse permission. So the users will be able to create issues in the project and as the reporter they will be able to see their issues, but not others. You may also want to allow them to edit their issues so you would give them edit authority. However, you can't restrict what fields they can edit without jumping though hoops or scripting so you may not want to give them that.  For the 'team member' roles such as developer, tester, QA, etc you'll probably want to give them edit and browse. Remember, without the browse permission they can't see the issue. Edit doesn't imply browse. 

3a. I usually create a team member role and assign most permissions to it and use the developer, tester, QA, and Admin to restrict transitions. For instance, only a tester can execute the 'passed testing' transition.

4. Never give delete issue to anyone. It will come back to bite you. The forum is full of people trying to recover issues. Have a resolution of 'deleted' I also don't delete comments. If you do the comment stream may not make sense. 

5. I mention the Watching role because I've often had users want to see every update for every issue in a project (not a good idea) Give them browse and put them in all the events in the notification scheme. Usually the ask me to take them out after a day or two. 

6. Using roles in notification schemes: Let's say the lead tester or lead developer for a project wants to know when any issue passes testing.

a.Create a special notification called 'passed testing',

b.  replace the event in the passed testing transition post functions.

c. Create Test Lead and Developer Lead roles

d. add the users to the lead roles

e. Add those roles, and any others you want to the notification scheme for the passed testing notification

I hope this helps. 

[Bruce Edmiston]

Hey Joe - I really appreciate all the info and it has helped .... after rereading your original post and starting again this is what I ended up doing ... if you think I've missed anything PLEASE let me know !

Writing it up just in case anyone else needs to refer to it ...

I have 3 teams of users 

Team A work on Project 1

Team B work on Project 2

Team 3 work on Project 1 and 2

All I want to do is make sure Team A cant see Project 2 and Team B cant see Project 1 and Team C can see both

I dont want to get too complex around permissions and who can do what - looking at the default permission schema I am happy to have 3 separate schemas (if needed) that are copies of this for each project that covers all users with access to that project.  A team member can wear many hats from design to dev to qa so dont really have a need to have complex permission schemas.

I think the following works ...

I have created a Group called 'Project 1 Team'

I have added all team members of Project 1 to the Group 'Project 1 Team'

I have created a permission schema (copied default) called 'Project 1 schema'

I have created a Role called 'Project 1 Role'

Going to Jira Admin -> Issues -> Permission Schemes -> Project 1 Schema I then added my Project 1 Role to all necessary permissions AND removed all permissions from 'All logged in users'

Using the screen (Administration  -> Projects -> Project 1 -> People -> Add People) where I can assign the Group 'Project 1 Team' to the Role 'Project 1 Role'

I also updated the Projects permission schema in the screen Administration -> Projects -> Project 1 -> Permissions -> Actions drop down -> Use a Different Schema (which makes me think I might not have needed to create the role) 

[Joe Pitt]

By using project roles you eliminate the need for multiple permission schemes. The problem was because you gave 'all logged in users' permission. As a rule you should never give that all users permission to anything unless you're absolutely sure everyone really needs it. I've only given it to an internal project to ask JIRA questions and to our internal help desk project 

[Bruce Edmiston]

Hey Joe - appreciate your extra responses and proding - just as an fyi "the problem was because you gave 'all logged in users' permission" - actually I didnt - I didnt actually get that far !  I was still working out where to start on paper and hadnt actually tried creating anything as I was woried I'd never find the screen again !

Anyway - thanks again.  I have to say I found it all a bit painful and I've written up the above in part so that I can go back to it if I ever need to do it again ! That said your info was of great use and I wouldnt have got here without it

Atlassian please take note - sorting out some very basic security / access rights for small teams is a nightmare for someone learning the tool.

[Joe Pitt]

It is basically the 'best practice' of only giving access to people that need it. I have one permission scheme that covers nearly all projects. By using logical project roles you can assign them to the relevent permissions. Then it is just a matter of assigning users to the roles. It doesn't matter if the permission scheme gives the QA role a permission and you don't use the QA role in the project and never put a user in it. My exception is historical or archived projects where the only permission given is Browse and that to the browse project role. 

[Christoph Schötz]

Hey - I guess reading https://confluence.atlassian.com/adminjiraserver073/managing-project-permissions-861253293.html should help you - you find some basics about the relationships between the permissions here https://confluence.atlassian.com/jirasoftwareserver073/permissions-overview-861256129.html.

Feel free to ask any questions you have during reading this.

What you basically need to do is to create a permission scheme for your projects using one or more project roles you assign the permissions to. Seeing the project and the issues within is the browse projects permission. Then you assign the permission scheme to the projects and assign the users to the project role you chose for them in the permission scheme.

Cheers

Christoph

[Bruce Edmiston]

Hey Christoph

Thanks for the response but having read the links you mention I don’t feel I have the knowledge to create the necessary access.

“A permission scheme is a set of user/group/role assignments for the project permissions listed above”

Sounds like it is what I want but the following text / description then loses me. What I wish to achieve seems simple in my mind but as yet I have not worked out where I need to start … frustrating and a blocker for us.

I found the most useful part the diagram in section "How do permissions get assigned?" but havent worked out my next steps.

Having read other posts it looks like I am not the only one who is confused. Over the weekend I have also talked to other ‘expert’ users of Jira (Agile consultants who use Jira daily on numerous projects) they suggest setting up a completely separate Jira account for each of the projects as setting permissions is complex and fraught with error - not an option I want to follow.

So … if anyone has a step 1, step 2 cheat sheet please let me know. To add to my original scenario – each group of users should have ‘full’ access to a project (ie in terms of permissions I am not wanting to restrict them within the project just stop them from seeing other projects)

Thanks

[Bruce Edmiston]

Christoph - thanks for your responses but Ive failed !  I am going round in circles trying to work out where to start in terms of creating a group or a role or a permission schema or permissions and whether I need to allocate permissions to roles or groups or projects or projects to groups etc etc.  

I havent found the magic answer in anythimng I have read and remain frustrated.  Do either of you have an 'abc' in terms of which order I should go about creating things ?  It might help me through the myriad of possible options