Is "Set Issue Security" permission needed if user shouldn't see the default issue security level?

[Arielle Unterberger]

I need to provide access to an integration contractor to a Jira project, and the project admin would like the contactor to access only the ticket that the contractor himself creates and be able to do most things on the ticket. 

I created a separate issue security level with "Contractor" and "Organisation", and granted most permissions to the project role (contactor), but this role doesn't have the "Set Issue Security", since I thought this would allow him to modify the issue security.  

But it says in the documentation that: 

• If the reporter of an issue does not have the 'Set Issue Security' permission, the issue will be set to the default security level. 

In this case, I selected the default issue security level to be Organisation, so that the rest of the org can continue creating their tickets as before.

But if the issue is set to the default security level, the contractor would not be able to see the issue he just created. 

Does this mean I should give the contractor role "Set Issue Security" permission? And since the "Org" issues shouldn't be visible to him, he would not be able to modify the Issue Security Level anyway? 

What is the best practice approach for this? Thanks! 
Are there other approaches for this? I was told this could be done by just a checkmark in Zendesk. 

Thanks! 

[Trudy Claspill · Accepted solution]

Hello @Arielle Unterberger 

You can find more information about the Set Issue Security permission here.

The permission is typically reserved for people who should have the ability change/set the security level for an issue. For a user that has that permission, they can only select from the security levels to which they have been assigned.

So, if you want the Contractor to be able to set the security level to Contractor for issues that they are creating, you will have to give them permission to set Set Issue Security.

Alternately you could use an Automation Rule to detect new issues created by Contractors and use the rule to change the Security Level to Contractor for those users. The Actor set for the Automation Rule would have to be a user that has the Set Issue Security permission for the project and is a member of both the Organization and Contractor security levels.

[Arielle Unterberger]

Thank you @Trudy Claspill ! 

[Arielle Unterberger]

@Trudy Claspill I have a follow-up question.

Since the contractor is integrating Jira with another system, the contractor needs to see the issues created by a service account in Project A, and any other Jira project (to which he doesn't have access, because he only has access to Project A and with the security level set). 

For the service account, I could create an automation that anything created by this account in project A can be changed to "Contractor" security level, but what about the other projects? 

Is there a suggested way of handling this? because what I can think of is that all projects would need to have a security level set (which is not ideal, since we already have a lot of projects). 

[Trudy Claspill]

Can you clarify what issues the contractor needs to access in separate sentences?

1. The contractor needs access to issue in Project A that are created by a specific account.

2. The contractor needs access to issues in "any other Jira project"...

It is the second item for which we need a more complete statement about the requirements. Does the contractor need to be able to see all issues in "any other Jira project"?

The contractor will need to be granted access (at least Browse Projects) to any project that contains issues that they need to see/access.

If there needs to be a limitation on which issues the contractor can see in a given project that needs to be handled using Issue Security schemes/levels.

You will have to weigh the effort of setting up the Issue Security against the "risk" of allowing the contractor to see all the issues in the project(s).