A complete guide to Jira Service Desk permissions pt.1

[#1]

Online security is not only about the technology and processes, but also about the people. Especially that over 95% of security breaches happen because of human error. And such error may give unauthorized people access to vulnerable data that not only our customers but also our employees entrusted us with. The best example is the recent news about big international corporations having a misconfigured Jira expose their servers. The same may happen also in case of service desks, seeing as nowadays we're in such a hurry to better resolution time that they may become at risk of cyberattack. 

We often act as though cyber security and ITSM are completely different areas, with work carried out by different people for different purposes. In fact they both contribute to how we run and manage IT, and they need to work together to provide the protection we need to operate securely in a modern digital age. - Joe the IT Guy.

Just like we should care about our online security, we also should make the best use of the tools that the modern digital age gives us. That's why, in this article, we focus on making Jira Service Desk a safe haven for your customers and employees' data with customer permissions. 

Guide to Jira Service Desk permissions

It's important to build your protection steadily. Start from the most basic things like defining project roles, organizing users into groups and organizations, specifying their roles within the service desk, creating permission and issue security schemes, and assigning them to each project.

Project roles

Each user can have a different role within the service desk: administrators, service desk team or customers. And so, the Jira administrators may create and configure projects, customers raise requests, and agents from the service desk team can comment internally (visible only on the issue) or share their comments with customers. Moreover, we can assign more than one role to each user. Remember that the new users (invited via e-mail or who signed up through the Customer Portal) are automatically assigned to Service Desk Customers project role.

If we want to check what project role a user is assigned to, we should:

1. Go to User management in Jira Administration menu.
2. Click View project roles in the Operational menu.
3. If the selected user isn't assigned to the correct role, choose Edit project roles and check the appropriate fields.

There's also another way to configure project roles:

1. Go to Users and roles in Project settings of the service desk project.
2. Click Add users to a role, type the username or email and select the role.

Also, we can create additional project roles, i.e. if we need a Service Desk Project Admin. There are only two steps we need to follow:

1. Move to System tab and choose Project roles in the Security section.
2. Fill the Name and Description of the new project role in the Add Project Role segment and click Add Project Role.

User groups

There are three user groups out of the box: 

• jira-administrators,
• jira-service-desk-users,
• jira-service-desk-team.

If we have an internal customer portal, we can classify our users according to their position that grants them a specific authorization level. So, Jira Admins will go to the jira-administrators group because they need all the permissions that are necessary to do their job properly. And a customer support manager or even a team leader of each service desk team will be assigned to i.e. jira-service-desk-project-admins.

To do this:

1. In User management, choose Groups from the side menu.
2. Name the new group and add it to the service desk.
3. Go back to Users and click Edit user groups in the Operations column.
4. In the search box, find the right group and click Join selected group.

It's worth to remember, though, that Jira Service Desk also enables us to create Organizations, but we'll discuss it later on.

Global permissions

The first thing to remember after creating user groups is to assign them the right permissions that apply to all projects on our instance. We can grant six permissions:

• Jira System Administrators gives the assigned user groups access to all administration functions;
• Jira Administrators is similar to the previous one, though limited. The assigned user group still can perform most of the actions included in the System Administrators permits but import, export, some more advanced configurations, etc.; 
• Browse Users is kind of tricky because it enables to select users or groups, share the issues, as well as make all this data in the system visible to the assigned user group. So, be careful when granting this and remember to make it available to those with the right authorization level within the service desk;
• Create Shared Objects enables us to share dashboards and filters with others.
• Manage Group Filter Subscriptions;
• Bulk Change comes in handy when we have to change or delete multiple issues at once.

Global permissions override the Permission schemes. Because of that, we should always grant adequate general permissions to user groups before defining which actions they can perform within a project. And if we can't give some permits to the users, it's probably because they're not assigned to the specific global permission.

To set up overall authorization for the user groups, we should:

1. In System, click Global permissions on the side menu.
2. Select new permission and a matching user group, and click Add.

Project permissions

We should pay close attention to what project permissions we give to the users, both internal and external, of our Customer Portal. For example, our clients shouldn't have access to every part of the platform, especially to the Jira Administrator menu where they would be able to butcher the most important configurations. That's why Jira Service Desk has various permissions we can grant to the users depending on their role, user group they belong to or other variables.

Permission schemes may differ depending on the needs of the project and what actions specific users need to be able to perform within it. Source: Tempo

As we can see from the graph, there are six groups of permission types that the user can get:

• Project permits define which actions a user can perform within the service desk project, i.e. if they can administer a project, browse projects, interact with customers, etc.; 
• Issue permissions decide what users can do on the issue level, for example, if they can assign issues or be assigned to them, close them, change the reporter, etc.;
• Voters and Watchers allow to see the voters and watchers of the issue, as well as manage the latter;
• Comments permissions enable users to add comments to an issue, delete them, edit, etc.; 
• Attachments permits include the most basic actions, such as adding attachments or delete them;
• Time tracking gives users the possibility to log their work, edit or delete it. This type of permissions is dedicated only to the service desk team, developers or administrators project role. 

Giving users permissions is quite easy. We just need to:

1. In Issues, choose Permission schemes from the side menu.
2. Tap Add permission scheme and fill the fields.
3. To view permissions within the scheme, move to the scheme's Permissions located in the Actions column.
4. Click Grant permissions and select permission, as well as whom will it be granted to. 

Remember that we can grant numerous permissions to each user group, project role or other variables available to select.

Project roles are useful for defining specific team members for each project. Referencing project roles (rather than users or groups) in your permissions can help you minimize the number of permission schemes in your system. - Source: Atlassian.

Want to learn more about issue security levels, customer permissions and organizations, and the ways you can extend the native permissions? Read the second part of the article.