What's the best way to make issues belonging to a customer only visible that customer within one project?


I'm looking to the best way to configure one project in JIRA to only show issues that belong to a customer to that customer and not the other customers within the same project.

As far as I could see, this doesn't seem to be possible with normal permission configuration and has to be set with issue security levels. If this is correct, then how do I set it up to get this working correctly?



1 answer

0 votes

Atlassian do it with the "reporter browse" permission - see https://confluence.atlassian.com/display/JIRA/Current+Reporter+Browse+Project+Permission

This only works for a user though - if your customers have several accounts and need to see other issues raised by other people from that customer, then yes, security levels are the best approach.

Thanks for the reply. As it seems, this "reporter browse" permission works at the project level. Which doesn't seem to fit my case. But correct me if I'm wrong. My case: Have a project and customers B and C. I want both B and C to be able to browse and edit all issues that belong to them in the project (same project for both). So I need a way to mark an issue as belonging to customer A or B (by the use of a custom field?) and then a permission that hides issues belonging to A from users of group B and vice-versa. I would believe that this is a common scenario.. come to a surprise that there's so little info on how to set it up..

Reporter browse lets you says "only let the person who reported the issue see it" - it works best in support projects where you have hundreds of customers but they should only see issues they raise. I'm not sure that is right for you - are you saying that B and C should see each other's issues? If so, then you need to use issue security and set the security level (A would be named in one level, and B and C included in another)

B and C should *not* see each others issues. but not only users from B or C will create issues. We will create issues as well on their behalf, which using the "reporter browse" permission would not show for them... unless we would always change the reporter user.. but that sounds like a lot of work..

Ok, I misunderstood. Reporter browse will work if B and C are both *users* (not groups of users), and if you are raising issues for them, you set the reporter to B or C as appropriate. If B and C are groups of users, OR you don't feel like messing with the reporter, then I'd definitely use the issue security - you can have a 1:1 scheme where you would define security levels: A - group A can see it, plus your internal users B - group B can see it, plus your internal users C - group C can see it, plus your internal users None - everyone can see it. I'd also consider having a "copy in" field. If you make it a multi-user select list, then you can have your internal staff add other users to it, and if you name it in your security level too, it can be handy

Yep that's the way to go. I have now configured it in that way and it seems to be working just fine. I would like to accept this as the correct answer, can you move/copy it to a separate answer? Thanks for the help!

Suggest an answer

Log in or Join to answer
Community showcase
Sarah Schuster
Posted Jan 29, 2018 in Jira

What are common themes you've seen across successful & failed Jira Software implementations?

Hey everyone! My name is Sarah Schuster, and I'm a Customer Success Manager in Atlassian specializing in Jira Software Cloud. Over the next few weeks I will be posting discussion topics (8 total) to ...

2,981 views 12 18
Join discussion

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you
Atlassian Team Tour

Join us on the Team Tour

We're bringing product updates and pro tips on teamwork to ten cities around the world.

Save your spot