Degraded performance Customers may experience intermittent errors using Community search. Our platform vendor is investigating.
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?
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
This community is celebrating its one-year anniversary and Atlassian co-founder Mike Cannon-Brookes has all the feels.Read more
Hey Atlassian Community! Today we are launching a bunch of customer stories about the amazing work teams, like Dropbox and Twilio, are doing with Jira. You can check out the stories here. The thi...
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!
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