nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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

John Price

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.

Accepted answers

Nic Brough -Adaptavist-

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.

All comments

Jobin Kuruvilla [Adaptavist]

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.

Nic Brough -Adaptavist-

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 (

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.

Nic Brough -Adaptavist-

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

Sorin Sbarnea (

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

John Price

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.

Tim Twisk

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

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

security