Restrict Access within a project

[Charles Delaporte]

We develop software and continuously add new features. Each software is managed as a project in Jira. Each time we make a client implementation, external consultants come up with new requests for improvements, bugs, etc,.... I would like to provide access to these external consultants, so that they access only to the issues related to their client/site implementation(s). The internal team needs to see all issues - i.e. all client/site implementations + internal issues..

What solution do you recommend?

Thanks. Charles

[Heshan Manamperi]

You can use "Issue Security Level" to achieve this. Create two security levels called internal and external. You should have separate project role for clients (ex: Clients) and not to add them to other roles who are exist internal users. you can add client role + all other required roles for external security level and add required roles except client role to internal security level. We also use same in Our JIRA as well.

[Ollie Guan]

Issue security levels are created within issue security schemes and let you control which user or group of users can view an issue. When an issue security scheme is associated with a project, its security levels can be applied to issues in that project. Sub-tasks will also inherit the security level of their parent issue.

https://confluence.atlassian.com/adminjiraserver074/configuring-issue-level-security-881683436.html

[Charles Delaporte]

Could you please confirm if the following solution would work:

- create a custom field as a drop down list with multiple values (site1, site 2, site3,...) - multiple values is important as some issues can relate to several sites.

- set up the security schemes based on this field

The expected result is:

- internal users can see all sites

- external users can see only issues related to their site

Additional question: can external users edit and/or create and/or comment issues for their site?

Thanks.

[Nic Brough -Adaptavist-]

>set up the security schemes based on this field

This can't be done natively.  A security scheme is a collection of "levels".  Each level is a set of rules for users. (e.g. Top Secret = only people in group X, Secret = people in roles X or Y, and so-on).  You have to set a level to apply the rules.

Other fields have no direct impact on security.  The only way to make them do that is to have code that looks at the custom field and sets a level for you automatically.

You are going to need to have one level per combination of sites in order to do this.

[Charles Delaporte]

Let me propose another solution:

- create a generic user for each site ("site1", "site2",...)

- set restrictions for these generic users based on the values of the custom field

Would this work?

[Nic Brough -Adaptavist-]

No, because you need to set the level.  The custom field is irrelevant.

[Charles Delaporte]

So there is no way to set different access levels based on a custom field ?

[Nic Brough -Adaptavist-]

No, the levels are set by the level field.

There are some uses for a custom field - a level can refer to a user or group picker on the issue, but that won't set the level for you and relies on your users setting them correctly.

[Charles Delaporte]

As far as I know, Jira is commonly used by service desk teams. Service desks usually manage several groups of users. How do these teams provide visibility to their different user groups, showing to each group only the information that is relevant to their group? For instance, the list of all outstanding issues for a given group?

[Nic Brough -Adaptavist-]

If they are using plain Jira, then they tend to split it up by project.  Some projects then use security levels if they're going to want to hide specific things.

You can also use the more dynamic features in permission schemes.  For example, in old Jira versions "Reporter Browse" in a project used to mean "allow reporter to see their issues, but no-one else's (unless allowed via another route)", and that was finally implemented properly in just "Reporter" a few versions ago.

Or, you can layer Jira Service Desk over Jira projects.  That splits your users into "customers" who see only requests that they raise, and possibly their organisation's requests, and ones they are explicitly allowed to.  This is NOT the same as Jira access, which shows the projects to Agents and Jira Users (the other two types of user for JSD)