How can we implement the concept of a customer entity in JIRA?

Andreas Betterm

We're looking at implementing JIRA for internal and external users.

However, we want to limit users field choices according to the customer to which they belong. In other words, if a customer uses projects x and y, we don't want users associated with that customer to be able to enter issues or even see issues for project z.

We also note that JIRA doesn't appear to have the concept of a customer to which multiple users may be attached. It would therefore be difficult to generate data pertaining to a particular customer or associate users with a customer.

This seems to be a major shortcoming. How do other organisations deal with this in JIRA?

Is anyone aware of any plug-ins we could investigate?

Nic Brough -Adaptavist-

Short answer is "groups". Put users in groups matching their customer.

>However, we want to limit users field choices according to the customer to which they belong.

Ok, well, Jira doesn't do field level security. There's a load more on that subject at https://jira.atlassian.com/browse/JRA-1330

But it is worth noting that it does do issue level security and of course, project level

>In other words, if a customer uses projects x and y, we don't want users associated with that customer to be able to enter issues or even see issues for project z.

Now, that's a doddle - you can use roles or groups to control access to projects. If you go for roles, then you set up a single permission scheme that says "Only people in role of users can browse", then you put customers into the user role for projects x and y, but not z.

You can also do this with groups, although I prefer to stick with roles even if I have got people in groups, because you can put groups into roles. (That avoids having loads of permission schemes with different groups)

One quick hint - whether you use groups extensively or not, you should define one group to mean "people who can log in" (the default is "jira users") and do not use that group in any permission scheme ever (unless you definitely have projects that should be completely available to all users)

I think you definitely need to be putting your individual customers into their own groups though - that will make sense to your users, is moderately easy to maintain, and you can then do reporting on "users in group X"