Granting isolated access to projects to individual customers

[Ulrik Gammelby]

Hi there,

I have played around with a toy account and believe I figured out how to accomplish what I need, but it seems incredible cumbersome for something that should be a pretty standard task. So I hope I have misunderstood something or at least there are some means for making the task simpler.

We have a few internal projects and several customer projects, all of which our own developers should be able to work on. We would like the individual customer to be able to access their respective customer projects - for simplicity (?) let's say they should have access as our own developers but only to their own projects. That is, the customer should be able to create work items, change state and browse work items. Each customer should be confined to only see the project(s) the given customer is associated with and not know about the other projects, even their names and existence.

Apparently this is not something that is supported out of the box, I tried to follow the basic user management tutorial and figured out the below is probably the way to do it (although there is not much explicit information on the exact problem).

So I went ahead and created the following test items:

• two projects "Customer A Project" and "Customer B Project"
• two users "Customer A User" and "Customer B User"
• two groups "Customer A Group" and "Customer B Group"
• two permission schemes "Customer A Permission" and "Customer B Permission"

I setup permissions and associations:

• granted all permissions but "Administer projects" to each scheme
• added the A and B users to the A and B groups, respectively
• associated the A and B groups to the respective permission schemes
• removed the customer users from the default "Users" group.

Apparently I now have the isolation and privileges needed.

But does it really need to be this complicated? Is there some fundamentally different thing I could do instead, for instance using roles (could not see how)?

If this is indeed the way to go, isn't there some kind of template or macro like way of simplifying or automating the procedure? Or do we have to manually walk through all the steps for each of the customer specific projects?

Thanks for any hints and/or pointers to documentation!

Ulrik

[Joe Pitt · Accepted solution]

Why not use the project roles? You can have the same role, say Customers, for each project and just put the users in the role that should be allowed in the project. In the permisstion scheme you give that role the access you want the customers to have in any project so you can use the same permission scheme for all projects. Most people get in trouble with access when they give the jira-user group access to a project. By default everyone ends up in that group when getting an id so they have immediate access to everything. The advantage of project roles is the project lead can add/delete people from the roles.

[Ulrik Gammelby]

Thanks for your input. I probably gave up too fast when playing with roles earlier; I started all over as suggested and it seems I managed to obtain the necessary isolation by just defining permissions at the role level and then adding the customer's users to a Customer role associated with the individual customer project.

On a side note: I could not find a "jira users" group associated with any permission scheme (has it just been renamed to "users")? Instead I created a new permission scheme with no privileges to the "Users" role, almost everything to "Developers" (our internal staff) and limited privileges to "Customers".

[Nic Brough -Adaptavist-]

It's not actually anywhere near that complicated, but Atlassian's defaults (i.e. what you get when you install a new Jira) make it a bit painful. They have a very open and show-everything default permission setup which is good for a lot of sites, and most people inherit that, work with it for ages, and end up with a lot of complex unravelling to do when they run into the "I want to limit someone to one project" scenario

If you have an empty Jira, then the approach is simple. You remove the group "jira users" from the permission scheme. Then you tell your administrators to NEVER use it for anything other than "this person can log in" (Exceptions may be bulk-edit, look up users and if you have a "jira support" project).

From that point on, you use groups and roles to allow access. Roles are far better than groups though (Joe already explained why, so I won't repeat it).