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

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:

 

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.
    Screenshot 2020-07-13 at 10.49.06 AM.png

     

  2. Choose the project role you would like to restrict the issue from the list of the project roles available for the project.
    Screenshot 2020-07-13 at 10.51.18 AM.png
  3. You can also restrict the issue to multiple project roles.
    Screenshot 2020-07-13 at 10.53.03 AM.png

  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.
    Screenshot 2020-07-13 at 10.55.11 AM.png

  2. Choose the roles you would like this issue to be restricted to
    Screenshot 2020-07-13 at 10.56.40 AM.png

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

Screenshot 2020-07-13 at 10.57.53 AM.png

 

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
    Screenshot 2020-07-13 at 10.59.01 AM.png

  2. Click on the lock icon on the top right of the Issue Type screen
    Screenshot 2020-07-13 at 11.07.14 AM.png
  3. Select the project roles for which you would like to grant access permission to the Issue Type and click Apply.
    Screenshot 2020-07-13 at 11.08.25 AM.png


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!

13 comments

Sachin
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
July 12, 2020

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

Martijn van Eijk July 13, 2020

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
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
July 13, 2020

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
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
July 24, 2020

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

Omar Hutchens October 16, 2020

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 December 4, 2020

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 January 7, 2021

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

Arjoon Som
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
January 7, 2021

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
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
June 27, 2021

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

Martin Kovalcik October 27, 2021

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?

G November 11, 2021

@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.

Like Cameron Gocke likes this
Cameron Gocke March 27, 2023

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

Like Dennis Chiuten likes this
Stacy S May 4, 2023

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). 

Like Dennis Chiuten likes this

Comment

Log in or Sign up to comment
TAGS
AUG Leaders

Atlassian Community Events