Managing roles and permissions - Jira Tutorial

- [Instructor] In this module, we'll explore project roles and permissions. We will learn about permissions, groups, roles, and permission schemes. We'll look at some common project permissions, how to manage role membership, and how custom roles can be used to satisfy specific team requirements. When discussing permissions in JIRA, there are several key elements that interact with each other. In this section, we'll examine those elements. JIRA's administrators are responsible for managing user access and permissions in JIRA. Each type of administrator affects different aspects of JIRA. A site administrator manages the JIRA instance, and grants access to users, and adds users to groups. The site administrator does not work with JIRA or JIRA projects. A JIRA administrator configures JIRA, which includes configuring roles and permission schemes, which we will discuss shortly. A JIRA project administer uses the permissions and configurations set up by the JIRA administrator to grant permissions to various team members. Permissions are settings within JIRA that control what users can see and do. JIRA has a variety of permissions, from whether users can create new projects to whether a user can see a specific type of comment on an issue. Permissions are different from application access, which is controlled by groups that have access for a JIRA product or application. Global permissions are granted to groups of users and can only be modified by JIRA administrators. Project-specific permissions let you restrict project-related functionality to individual users, groups, or project roles. For example, who can see the project's issues and who can create, edit, and assign them. Project-specific permissions can only be modified by JIRA administrators. Group memberships give users site and product admin permissions. Groups apply to all Atlassian applications on an organization's site, such as JIRA and Confluence. Site administrators create groups and manage membership. Global permissions are assigned to groups, and project permission can also be associated with groups. Project roles are similar to groups, except that while groups apply to the entire site, roles are scoped to a single project. Additionally, group membership can only be altered by site administrators, whereas project role membership can be altered by project administrators. Project roles can be used in many places, including permission and notification schemes, issue security levels, workload conditions, and common visibility. They can also be given access to issue filters and dashboards, but the core usage is for permissions and notifications games. While you could assign permissions and notifications to users in groups directly, roles are more flexible and sustainable. Many JIRA project configurations are implemented through the use of schemes. Schemes are essentially a container that holds a particular kind of configuration. For example, there are workflow schemes that describe how workflows behave, notification schemes that configure notification roles, and so on. All schemes are configured by a JIRA administrator, and then associated with one or more projects. In this way, a set of configurations can be defined once and then applied to any number of projects. A permission scheme determines who performs certain tasks in a project. It is simply a list of permissions along with users, groups, and/or roles they are associated with. In this example, the permission requirements in all development projects are the same. So the JIRA administrator has created the development permission scheme and applied it to all development projects. Any logged in user with application access can browse projects and edit issues, but a user needs to be in either the project administrator's role or the scrum masters project role to manage sprints. When there are multiple entries in a particular permission like this, it's treated as an and/or statement. The user doesn't have to satisfy both, but either of the choices. After the JIRA administrator creates a permission scheme and assigns it to a project, the project administrator can add a project to users, to the roles listed in the permission scheme, granting the permissions associated with the role. Now, we'll take a closer look at some of the project permissions. JIRA has two levels of permissions, global permissions apply to the entire JIRA instance and determine things like whether users can see other users accounts in groups, shared dashboards, and filters, make big changes in projects, and so on. Global permissions are assigned to groups by the JIRA administrator. Project permissions apply to individual JIRA projects and determine the types of action users can perform within a project. Issue security permissions allow the visibility of individual issues to be adjusted within the bounds of the project's permissions. For example, issue security permissions can let you set up types of issues that can only be seen by project admins or users in specific groups. Issue security permissions allow the visibility of individual issues to be adjusted within the bounds of the project's permissions. For example, issue security permissions can let you set up types of issues that can only be seen by project admins or users in specific groups. JIRA administrators configure project permissions using permission schemes that are then associated with individual projects. We'll take a look at some examples of project permissions on the next slide. Browse projects is the most important permission. No matter what other permission the user may have, if they do not have the browse projects permission, they cannot see the project or any of its issues. Permission to transition issues is needed above any other specific permission that may be used in a workflow condition. Schedule issues allows the users to set the due date. Normally, you only need edit issues permission to edit fields, but for Due Dates, you need the schedule issues permission. The schedule issues permission and the edit issues permission are both needed to rank issues in the backlog of a software board. Ranking is a feature that is only available to JIRA software users. Manage sprints allows users to create, schedule, reorder, start, and complete sprints in a software project. But boards, and hence this permission, are only available to JIRA software users, so they only need your software application access. Note, that there is a distinction between assign issues, which allows someone to make assignments, and assignable user, which allows someone to be the assignee. Move issues allows a user to move issues between projects and/or change an issue's type. For every JIRA project, a default set of roles is provided. Each role has specific significance and capabilities in a project. An additional default role component lead is also created when a project utilizes components, which we will cover later in this course. The JIRA administrator assigns one or more users to be a project administrator for a project. The project administrator can perform basic project configurations and is responsible for assigning team members to the other project roles. We'll take a closer look at the default project roles in the next few slides. The project administrator can edit the project details. For example, name, description, avatar, and URL, as well as the project lead. But their most important responsibility is to edit project role membership. They can also define project components and versions. By default, when a project is created, the JIRA administrator's group is assigned to the project administrator's role. The project lead is a person who manages the project. By default, the project lead is the project's creator, but it can be reassigned to any team member. The project lead can be designated as the project's default assignee for newly created issues. This role is often fulfilled by the project manager or the lead developer. The default assignee is the person who is assigned to a new issue if no assignee is specified. There are only two choices, unassigned, which is the default, or the project lead. The JIRA administrator can configure JIRA to disallow unassigned issues, in which case the project lead is the only choice. The board administrator is able to configure a specific JIRA board. For example, they can add columns, configure card colors, et cetera. By default, a board's creator is automatically assigned as the board administrator. A board can have more than one board administrator. You should know how your team works and what each of them needs to do their work in JIRA. Then you can set their roles and have the JIRA administrator set their permissions in the projects appropriately. For example, some teams may be hierarchical, like this marketing team. They have that one person, the project manager who is in charge, and who will have the most control. So that person will be the project lead and the project administrator. Other team members will be users with the ability to manage their own issues. Other teams, for example, agile software teams, may want to manage their own projects and have everyone in the team have all the project permissions. If the default roles are not sufficient to satisfy your team's permission requirements, the JIRA administrator can create custom roles, which can then be referenced in a permission scheme and assigned to JIRA projects where they can be used like any other project role. Typical situations where custom roles are needed is when common permissions that are widely granted to all users need to be narrowly restricted to a smaller subset of users, or when certain users need to perform specific functions they normally aren't allowed to do. Most issue-related permissions are granted to the default group of JIRA software users. If this default group is assigned to for instance, the developer's project role, then you might be giving broad issue permissions to users who are not part of the development team. Some organizations are comfortable with this situation, but others prefer exerting more control over access to the team's backlog. In this case, the project admin can just remove the default group from the project role in question, then create a custom role to grant permission to specific users. By default, the manage watchers permission is associated with the administrators' group for a project. To grant selected administrative permissions to other team members, the permission can be associated with a custom role and the selected team members can be added to that custom role. Now we will look at some specific use cases related to permissions. In this example, certain team members need to be able to delete issues, which normally only administrators can do, but we don't want to give full administrative positions to these team members, they only need to be able to delete issues. The solution is for the JIRA administrator to create a custom role and assign the Delete issues permission to that role in the new permission scheme. Once the permission scheme is associated with the project, the project administrator can assign users to that role, granting them the ability to delete issues. If this requirement wasn't limited to a selected project, but applied to all JIRA projects, creating a new scheme wouldn't be necessary. The JIRA administrator could simply modify JIRA's default permission scheme that is applied to all JIRA projects by default. To edit project role membership, select Project settings, People. This page allows you to view the project roles and their respective membership lists, as well as add and remove users. Groups are created and managed by the site administrator, so they're in control of group membership. While it's possible to add a group to a project role, the project administrator will not be able to make any adjustments to the group membership. Therefore, it makes sense to add only users to project roles. For this requirement, the ability to start and stop sprints should only be granted to selective team members instead of all users, which is the default. In this situation, the JIRA administrator creates a custom role and a new permission scheme, and assigns the Manage sprints permission to that custom role. Also, a part of the JIRA administrative permission scheme configuration would involve removing the Manage sprints permission from all users, so that the permission is only restricted to the custom role. When a user is added to a project's administrator's role, they become, a, project administrator for that project, b, JIRA administrator, c, project administrator for all JIRA projects, or d, site administrator. The answer is on the next slide. a, project administrator for that project. Project roles are specific to individual projects. A user may be a project administrator in project A and a regular team member in project B. How do project administrators manage permissions within a project? a, assign permissions to roles, b, add roles to projects, c, assign permissions to projects, or d, add users to project roles. The answer is on the next slide, d, add users to project roles. Project administrators are not able to manipulate the individual permission settings, instead they can grant permissions to users by adding those users to project roles with specific permissions. Some takeaways from this module are, project administrators manage project permissions by editing project role membership, and project administrators must work with the JIRA administrator to create and apply custom roles to a project.