I am trying to setup 1 tracking system for issues across multiple customers. I don't want the customers to see each others issues but our internal employees need to see all issues.
For example, let's take ACME Corp and Beta Corp as customers with Sally and Mike as users.
I want Sally to view any issues associated with ACME Corp (she may of entered them or support might have entered them for her). Mike should see all issues for Beta Corp.
John is a support report that needs to see both ACME and Beta Corp issues as well as being able to report an issue for Sally or Mike.
Ideally there are 2 other categories of issues as well. John could create an issue that is private to only the company. He could also create a public issue that both Sally and Mike would see.
I believe the answer is a combination of permission schemas and issue security but I have not been able to get the desired functionality correct.
Thanks in advance for any help.
You're on the right track.
Start with permission schemes - this bit is easy. Does a person need to see anything in the project? If yes, then they need browse permission. If they need the be assigned any issue, they need "assignable user". And so-on. It's purely a project level access thing, nothing to do with the separation of organisations you are looking at. (Pay attention to the "set security level" - you probably want to let them all have that)
So, now you've got a project that all of your customers can see.
Now, you will need to logically group everyone from Acme together somehow, then something different for Beta Corp, and something for your employees. By far the easiest way is the obvious "put all Acme users in a group called Acme, Beta Corp people into a Beta Corp group, and your people into Employees" and so-on, but that really is the most simple case.
Then, you define a security scheme that has security levels of "Acme" and "Beta", with the Acme one saying "Only employees and people in Acme" and the Beta one saying "Only employees in Beta".
Then extend these rules to cover your other cases.
Hi Steven Take a look at my comment here: https://answers.atlassian.com/questions/325771/answers/2821063 . Which is very similar to Nic's approach, but, through the use of the Automation plugin we automatically set the security of the issue based on the users group memberships. Seems to work nicely.
Oh, yes, if you've got access to plugins, then you have loads of automation options. I've used the script runner and my own simple plugins to set it automatically. Not tried it with the automation plugin, but it sounds like that's just as good an option.
Not without a bit of code. I can't remember if you can set the field as mandatory in the field configuration either (that fixes "none" in custom fields, if you set a defualt, but it may not work for security level because some people may not be in the default rule)
The Jira Marketing team is putting together an ebook on migrating to Data Center. We're looking for pro tips on how you staffed your project team and organized your Proof of Concept. Share yo...
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