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; } } }

Multiple Customers, single project - How to set it up?

Steven Tucker

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.

Accepted answers

All comments

Nic Brough -Adaptavist-

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.

Steven Tucker

When a user in Acme creates an issue will it automatically go into the Acme security group? This was not happening for me but I suspect it was due to the fact the Set Issue Security was not enabled.

Nic Brough -Adaptavist-

Not automatically, although you can make the field mandatory (users can only select levels they belong to)

Steven Tucker

I think I am almost there. I think this is my final question, Is it possible to remove None from the list of options in the Security Level drop down?

Nic Brough -Adaptavist-

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)

unknown

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.

Welcome!

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

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud