Assigning a group of staff to one project.

[Darren Smith]

As simple as that. That's all I'm after.

From the online suggestions, processes and comments I've read that go back to 2012, 2015 and some more recent - some suggestions work for some but not for others.

Essentially, we have one new project that I'm creating about four or five new staff to access and that's it. No transitioning between other projects. No looking at other projects. No searching for other projects - just a new project, dump new users into project, job done.

Except I appear to alternate between denying the user even logging into JIRA to begin with (now solved) - to them still having the ability to snoop around.

It really can't be this convoluted, can it? It appears to me that the whole structure and ethos of the way JIRA assigns permissions is completely the wrong way around. It's like wanting to learn the alphabet and expecting to be given a bunch of 26 letters. JIRA's view of the world is that should you want to learn the alphabet, that you need to be aware of sentence syntax, grammatical pitfalls and maybe a solid understanding of active pronouns. None of which are remotely relevant until you get control of the basics.

Maybe I'm tired with it being a Friday afternoon - but I think if I click on an another JIRA administration screen that takes me down yet another completely irrelevant rabbit-hole, I think I may just punch a hole through my monitor.

[C_ Derek Fields · Accepted solution]

You are correct. It isn't that difficult. There are three levels of security in Jira and you need to understand them in order to make what you want to do work.

1) The first level is the User. They are your base. They are able to access your Jira site because they belong to a Group that gives them access. Typically, this is the "jira-users" group. 

2) The second level is the Group. Groups are global to the site. If a user is in a group (e.g., jira-users), then they are part of that group for all projects.

3) The third level is the Project Role. Membership in a project role is specific to the project. The members of the Users or Administrator Project Role can be different from project to project.

The way to accomplish what you want is to use Project Roles to determine which users can access which projects. You do this by using a permission scheme that limits the ability to access the project (the Browse Projects permission) to members of a Project Role. You may be using a current Permission Scheme that enables any logged in user to have access to the project. Update this permission scheme so that only members of the Users and Administrators Role has Browse Permissions. Then put the users who you want to be able to access the project into the Users role and put yourself into the Administrators role so that you continue to have access to the project.

You will need to do the same for the other projects so that they are restricted to only the people who should be able to access them. 

[Paula Hidalgo · Accepted solution]

I'm sorry to say, your monitor may be acquiring a hole.  A Jira Security decision is typically made when you instantiate your Jira Cloud.  As a Site Administrator (higher level than Jira Administrator), this information is available under the Products ... menu item "Manage Access".  The groups listed have product access.  The groups with product access are in the "Application access (Any logged in user)" category.

As a Jira Admin, you set Permission Schemes for use with your projects.   In our cloud, any one with "Application access" has the "Browse Projects" permission in every Permission Scheme.  In your case, if a single Permission Scheme has the "Application access" allowing "Browse Projects" permission, your group of staff will see those projects and all issues (caveat: except issues that do have issue level security) contained therein.

You can set your Permission Scheme for the project used by your staff but the rest of the Permission Schemes in your cloud allows the staff to view other Jira projects.

Hope this clarifies your research.

[Darren Smith]

Thanks Paula and Derek. I'm back on with this today so I'll see how I get on.

As you mention Derek, I had thought that the permissions were similar to that. However, I thought they were much more 'simplistic'. So that I would simply create a Sales Project, create a Sales Group that can only see the Sales Project and then create users that are solely Sales Group members. Not that I'd really have to then plug holes and protect all the other projects too.

Sigh. I'll get there. It's just a bit frustrating when I've told others that it 'shouldn't take too long' and yet its proportionally taking up a lot of time. It really should be more simple than this.