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
Badges are a great way to show off community activity, whether you’re a newbie or a Champion.Learn more
As part of the Bitbucket product team I'm always interested in better understanding what kind of impact the use of our tools have on the way you work. In a recent study we conducted of software devel...
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