Can Jira allow all users from one customer to see each others' issues?

John Price
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
August 27, 2012

I hae a scenario where a Jira customer wants to give many clients access to the system. Users from a single client need to be able to see each others' issues but not those of other clients.

I have done a lot of Jira installations, but there's a problem with each option I've used before:

1) Project-per-client - fine with a few clients but if there are dozens or hundreds, it's not workable. Also, this leads to duplication of Components, etc.

2) Reporter and internal users can see issues - This is like Atlassian's support setup I think. Each reporter sees only his or her own issues. However, two users from a single company cannot see each others' issues.

3) Issue security - I tried in the past creating groups for each client and using issue security. So like "Internal + Client 1", "Internal + Client 2", etc. This mostly works except that users from the different clients can see each others' names in the Assign dropdown.

Has anyone successfully set this up as I've described? Each Client 1 user should see all issues that were reported by Client 1 users.

Thanks.

5 answers

1 accepted

3 votes
Answer accepted
Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
August 28, 2012

I've done it several times. The basic tricks are

  • Enable the reporter-browse option and use it (just setting "reporter" as browse doesn't work, you need the special permission which is turned off by default)
  • Create an additional field, make it a group-picker
  • Make sure each individual client is in a group representing their organisation
  • Use a post-function in the "create" transition to set the group-picker to the groups that the creator is in (you need some code for that - script runner plugin makes it easy. I wrote it myself when I first needed to do this, before the script runner was around)
  • Do not allow editing of the group-picker. Heck, you don't even need to display it!
  • You permission scheme should start with Browse = reporter-browser, group-picker and a group (groups, roles, whatever) to identify your developers and internal users. I'd probably add a "user picker" too, to allow people to add other users, but that does expose your entire user base to everyone, so it might not be appropriate

This approach gives you the minimal effort on the part of all your users, they don't need to think about it at all.

Sorin Sbarnea (Citrix)
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
November 14, 2012

The tricky step is the post-function - can you share the code on this? All the other steps seems quite clear.

Tim Twisk January 21, 2016

3yrs later and the problem still exists .... I would like to see that code as wel, thanks in advance

2 votes
Jobin Kuruvilla [Adaptavist]
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
August 27, 2012

You can just extend option 2. In addition to reporter and internal users, give the view permission to a custom field as well. The reporter can modify the issue to add more users into the custom field.

It is more like the "cc" field in the Atlassian support system. By doing this, you are giving access to only reporter and internal users plus the users they added into the custom field.

0 votes
John Price
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
November 14, 2012

Nic's answer seems best but I ended up going with a hybrid of #1 and #2. The customer has some big clients and a lot of small ones who may only have one issue ever (this is for engineering requests like structural drawings, mapping, etc.). Here's what we did:

* Big clients get their own project and dashboard and have multiple users.

* Many small clients share a single project and have one user they log in as.

* I created a few custom issue types with nice icons: Construction, Inspection, etc. and all projects share the same issue type scheme. I used these in lieu of Components and each issue type has a custom field that serves as a more detailed request type.

* I wrote the client a simple wiki doc to explain how to create a new client project. They use the Copy Project script runner script and then add a new user group and change a couple of project settings.

So far they are very happy with it. The use of custom issue types made it really easy for their staff to see reports of, say, all open Inspection items across projects.

0 votes
Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
November 14, 2012

Er, there is no "simple solution". The use case is complex, and that means a complex solution. There's two approaches already as answers.

0 votes
Sorin Sbarnea (Citrix)
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
November 14, 2012

Can you describe what you opted for? I think that your use case is a very common one and I am impressed that Atlassian failed to present a simple solution for it.

Suggest an answer

Log in or Sign up to answer