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

[Andreas Bettermann]

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- · Accepted solution]

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"

[Beth Schaefermann]

The link appears to be broken. Was another link intended?

[Beth Schaefermann]

While they appear to be the same, the second one works for me while the first one still does not. Odd, I know.

[Radu Dumitriu]

No. The project is JRA, issue is JRA-1330.

https://jira.atlassian.com/browse/JRA-1330

[Radu Dumitriu]

Well Beth, this is because you downgraded me. "Atlassian Answes" looks deep in your soul :)

It's a bug

[Nic Brough -Adaptavist-]

It's the bloody awful editor in "answers" - you paste in a link and it idiotically pads the url with control characters while it's trying (and failing) to be clever or helpful. Apologies for not compensating for this particular bug in answers, but I forget how broken it is and accidentally assume it works sometimes.

[Radu Dumitriu]

Ok, reported: https://jira.atlassian.com/browse/ANSWERS-226

[Beth Schaefermann]

I had to get my Critics badge somehow, and what better way than on a RTFM comment to someone struggling to newly understand administrating permissioning, which, I would argue, is not as simple and straight-forward as you describe? I've read it twice, and I am still, personally, getting my head around it and workng to gain a level of comfort with how this would scale for a global enterprise. I think this is a good topic and will add more commentary on it myself once I have achieved that level of comfort. :)

[Radu Dumitriu]

Beth, I was joking.

[Beth Schaefermann]

As was I - halfway. The serious half is just working through it to figure it out in order to ensure a "safe" and "maintainable" release.

[Markus Lepper]

@Nic:

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)

Right, but this allows the project leads to update the role members (which we would likr to avoid).

=>Therefore I needed to defined one permission scheme per project (as the schemes are available to admins only)

Any better solution? (Kind of "right to change role settings" fur usage in a generic permission scheme?)

BR, Markus

[Nic Brough -Adaptavist-]

Better solution? No, because there isn't one - people can either maintain user access or they can't. If you want to stop your project admins looking after your lists of users, you'll have to drop the usage of roles for anything they should not have access to an restrict that to groups. Then your system admins handle that.

[Radu Dumitriu]

1. @see Security schemes

2. Use groups to group users. It is therefore NOT difficult at all.

Please RTFM. Jira is a very good choice for your needed setup.

[Mahesh Markus]

First you need to get familiar with all the various schemes.

• Permission scheme - who can do what in which project
• Notification scheme - who is notified when an event occurs
• Security scheme - who can see the issue

Couple that with roles and groups

Roles work at the project level and you can use the permission scheme to identify what level of access that role should or shouldn't have.

Groups are a collection of users. A role can contain zero, one or more groups. A role can also contain zero, one or more users.

To make things easy for you to manage...

Add all your customers into groups - by customer, customer department or similar

Add these groups into the specific role within the project

Use the permission scheme to define access for roles (instead of groups) - this way you can re-use the same permission scheme.