🎉 Managing issue security just got a whole lot easier!

[#1]

We know that many teams capture confidential and sensitive information in their service projects. We hear this from many teams, but especially those in HR, legal and finance where it’s crucial that certain information isn’t shared beyond a specific, limited audience.

That’s where issue security comes in - a platform feature designed to lock down issues to the right people. But this can be difficult to set up. That’s why we’ve made a few changes to help make it easier.

A new way to manage issue security on request types

We’re excited to announce that you’ll be able to better apply issue security levels in request type configuration alongside request type restrictions. This means you’ll be able to manage both who can view issues and who can raise requests in one centralized place.

We’re introducing this new feature in the coming weeks to give you more control and confidence when it comes to knowing how request types are locked down. Plus for those who use default security levels, you’ll now have better visibility of how it applies to request types in your project. Read more about restricting request types

From your company-managed service project, navigate to Request types and select the request type you wish to restrict. Here you’ll find the Restrictions button where you’ll be able to determine who can raise requests and/or who can view issues using specific request types.

This means you’ll no longer need to add the Security level field to request types in order to set a level on specific request types. Instead, you can choose whether to always have your project default level set even if your scheme changes, or use another of your levels for a particular case.

For example, you might have a generic security level called ‘Restricted’ set as your scheme default, giving all agents and admins access to any issue raised in your project. However, for the ‘Ask a sensitive question’ request type, you may want to set this to a more granular security level where only certain authorized staff have access.

You’ll also notice that admins can now view all security levels available in their project when configuring, with levels broken into Member and Not a member. As is the current behaviour, if you apply a level that you’re not a member of you won’t be able to view these issues once created.

A new scheme for all new service projects

We’re also rolling out a new default issue security scheme for all new company-managed service projects that will come associated in all new service projects to help you get set up quicker. If you want to associate this scheme to existing company-managed projects, go to Issue security and choose Select a scheme.

It has two levels:

• Sensitive cases: These issues will only visible to the assignee and the reporter to lock down access to the most restrictive audience. This is recommended for use cases like HR case management where the information is extremely sensitive.

• Service desk team: This will restrict the work item to the reporter and the service desk team (as well as the assignee, project lead and project admins). This is recommended for less critical use cases, such as HR queries, leave requests, contract management etc.

Like all things out-of-the-box, this scheme can be used as is but we do recommend customizing it to better suit your needs. Here are some options:

• Creating new levels: Add new levels if you need different levels of access, such as restricting issues to a subset of a team, restricting to specific people in your business or adding levels that exclude the reporter.

• Adding custom fields: Add user or group picker custom fields if you want to make issue security levels dynamic. For example, you could create a multi-user picker and add that to a security level. This would mean that the issue would be visible to the people you specify with that field.

What's next?

We are now in the process of rolling out these features to all sites throughout November. We’d love your feedback on these new capabilities for issue security, so please share your thoughts with us and let us know how you use issue security in your organisation. We’d love to hear from you!

[Harrison Ponce]

Wooo!!! This is awesome. Can't wait to test it out! Much needed!

[Tim Eddelbüttel]

The screenshot shows the default that will be get rolled out or just a random example?

The Sensitive Cases level in practise might be not usefull at all and is another things that must be re-configured by default, but for story telling it's okay but that shouldn't go into any instance by default.

The Service Desk Team (which should reflect a default so that collaborators don't see all issues) role isn't perfect. It misses the "Customer Portal Access" role and therefore request participants won't see the issue. Was this known issue https://jira.atlassian.com/browse/JSDCLOUD-4339 handled properly?

The project role atlassian-addons-project-access is also missing, if for example Automation for Jira isn't bypassing security levels (on DC it would respect it) the regular automations will not work and also other apps will not work on these issues.

[Sam Knight]

Hey Tim, thanks for the message! We had a lot of feedback that creating a new security scheme from scratch was extremely tricky to navigate. Editing existing schemes is a task that proved much simpler.

We wanted to create a starting point that could be edited to requirements, and so we didn't want to include too many roles in each level to reduce the amount of things that need to be deleted.

Thanks!

[Simen Vågsæter]

When will this be rolled out for all? Still missing this.