Announcement: Control access to your issues on next-gen using Issue Restrictions

[#1]

TL;DR

Project admins can now set up and control access to individual issues or set a default restriction to issues of an issue type for a next-gen project.

What has shipped?

Until now, the ability to restrict access to an issue was available only on classic Jira projects. Using the issue security feature, admins or users with appropriate permissions can ensure selective viewing rights to issues that should be visible to certain users only and not to every user in a project. Learn more about issue restrictions on classic projects

We are excited to announce that admins or users with appropriate permissions of next-gen projects can now restrict an issue or issues of an issue type to a role or a set of roles for a next-gen project.

Please note, to set issue restrictions for issues in a next-gen project:

• You must either be on the Jira Standard or Premium license plans.

• You are assigned to a role that has the SET_ISSUE_SECURITY permission. Admins and users assigned to the Member role are given this permission by default. Learn more on how to grant permissions to roles in next-gen.

How do I use it?

Customers can choose to restrict issues for the next-gen projects in several ways:

A. Restrict issues individually
For new issues - To restrict access to a system-defined role or a custom role while creating an issue:

1. Click on the ‘Restrict Issue’ dropdown in the Create issue modal. If the ‘Restrict Issue’ field is not visible to you, please ensure that the conditions specified above are met and that the restrict user field is configured for this screen.
   

2. Choose the project role you would like to restrict the issue from the list of the project roles available for the project.
   
   
3. You can also restrict the issue to multiple project roles.
   
   
   
4. Click Create, and your issue with the configured restrictions will appear in your project.
   
   

For existing issues - To restrict or modify the access to an issue in your project that already exists:

1. Open the issue in the issue viewer and click on the lock icon on the top right corner. If the lock icon is not visible to you, please check if the conditions specified above are met.
   
   
   

2. Choose the roles you would like this issue to be restricted to
   

You can also add or change the restrictions of existing issues from the issue viewer available from the sprint view as well by clicking on the lock icon in the top right corner of the issue

B. Set default restriction for issues of an issue type
If you would like to set up a default restriction for all issues of a certain issue type in a project, you should:

1. Open ‘Issue Types’ in the project settings of the next-gen project and select the Issue Type for which you would like to configure restrictions for
   
   
   

2. Click on the lock icon on the top right of the Issue Type screen
   
   
3. Select the project roles for which you would like to grant access permission to the Issue Type and click Apply.
   
   

Please note that changes to the default restrictions of an Issue Type will only apply to new issues that are created. For already existing issues of that Issue Type, you will have to individually change the issue restrictions accordingly.

We hope this feature will give admins of next-gen projects more flexibility and control of their projects. Please do leave your feedback and thoughts in the comment section below. We’d love to hear from you.

Thank you!

[Sachin]

This is definitely a great addition to the next-gen projects! Thank you!

[Martijn van Eijk]

I would like to be able to add the "reporter" of the issue to the allowed roles. So that the reporter can view its own issues, but not the total board.

[Arjoon Som]

Hi @Martijn van Eijk , unfortunately, restricting the issue to the reporter is not supported in next-gen projects. We only support project roles for the time being but we hope to expand this capability in the future. 

[Taranjeet Singh]

@Arjoon Som Thanks for sharing this useful new feature added for next-gen projects.

[Omar Hutchens]

This is a great feature. I would love to see that issues get restricted individually based on what role creates an issue. 

Trying to setup an automation where if a team member creates an issue - it's only for "team member role". If a Project viewer creates an issue then there is no restrictions. 

[Christopher Morello]

Hi, @Arjoon Som thanks for this!

Is there a known issue re: Set default restriction for issues of an issue type

Here's what I did:

1. Created a new access role called "Confidential File"
2. Only granted myself the user role "Confidential File"
3. I created a new issue type called "Customer PII" and set restriction to "Confidential File" role only
4. When I create new "Customer PII" issues, everyone in the project can see them.

Did I miss a step? Is there a bug here? It seems it only hides the issue if I manually click it after I create the new issue.

Also... how do restricted issues with story points affect burndown charts?

I noticed that when I manually restricted the issue, I can see 12 story points in the sprint, but everyone else can now see 11.

Does that affect how people see the reports too?

Thank you!

Chris

[Jason Sandoval]

I'm seeing this issue as well when setting the default restriction for an issue type.

[Arjoon Som]

Hi Christopher & Jason,

Thank you for your comments. The issue restriction default-ing happens only via the issue create modal. If you were to use another method to create an issue, for example, through inline create on your respective board or backlog screen, the default-ing will not happen and you will have to manually assign the restriction post creation of the issue.

Can you please check whether an issue of the type for which a default restriction has been set, when created via the issue create modal, is restricted by default post the creation of the issue?

Thank you,

Arjoon Som
PM, Jira Cloud

[Esther Strom]

@Arjoon Som - has this information made it into the official documentation? I'm not able to find any reference to it.

[Martin Kovalcik]

Example:

Task-1 is under Epic-1

user with no access on issue Task-1 can still see Task-1 in the list of child issues of Epic-1 on the detail view of Epic-1

bug?

[Greg D]

@Arjoon Som looks like this is not available in Jira Service Management Team-Managed projects.  Will that be available any time soon?  Service projects are the most sensitive since it is a lot harder to control what customers might discuss.

[Cameron Gocke]

I had the same question regarding Team Managed Service Management projects. This would be ideal to set privacy restrictions in those types of projects.

[Stacy S]

Same issue here, but for Jira Work Management team-managed projects. 

It looks like Jira Software team-managed projects now have limited role-based issue-level restrictions (i.e. the lock appears on individual issues), but the permission still does not allow for just permitting a reporter to see their issues (e.g. Admin + Reporter), which makes using the team-managed projects impossible for anything even remotely sensitive.

I saw there is work underway to decouple forms submission from project permissions here (https://jira.atlassian.com/browse/JWMCLOUD-107), which helps, as it would enable a project to collect submissions without requiring project access be granted, but it's not clear from what is listed in the ticket if/what visibility a user who submits a form would then have to be able to see the results and progress on their submitted form issues. 

Ideally, the "Create project issues" granular permission would solely relate to issue creation (via forms or "Create"), and two separate view permissions would be added, "View their own issues" and "View all project issues").

Separating create issues and view issues (and enabling limiting to just viewing their own) would be a powerful way to broaden project interactions without granting excessive access to those who don't need it.  For additional context, we're trying to manage security issue submissions, so limiting view access is important (as with the Service Management use case listed above).