In this video we will discuss Permissions. We will start by discussing Global permissions. Jira's Permission Model works by granting permission to users. If a user can see or do something, that means that the user has been granted that permission. For example, the difference between a standard user and a Jira administrator is that the standard user has not been granted the administer Jira permission. Managing users and groups, application access, and administration access applied to the entire site. Now we will move to the Jira application level of the interface. We will discuss Jira's Global Permissions which define what a user can see and do in the Jira account. There are six Jira Global Permissions. Administer Jira allows users to create and administer projects and perform most administration tasks except for managing users, importing, and exporting data, and editing system email settings. Browse users and groups allows users to see the names of users and groups on the site. Share dashboards and filters allows queries to be shared as dashboards and filters. Manage group filters subscriptions lets you create and delete group filter subcriptions. Make bulk changes allows a user to modify multiple issues in one step. Create next-gen projects is a relatively new permission. Users can create next-generation projects that do not leverage or affect the existing projects. A team could configure this project without a Jira administrator. By default, any logged in user can create a next-generation project. If an organization wanted to control next-generation project creation, they could limit this global permission to only certain groups. To view and manage global permissions, navigate to Jira's settings, select the system tab, and then select global permissions. On the left, we see the list of permissions. On the right, you can view the groups that have the associated global permission. You can click on the view users links to navigate to the group's tab of site administration. The administer Jira permission is unique in that even though it is shown on the global permission's page, it is managed by providing a group access to Jira administration. When you click on a link to configure permissions in user management, you are brought to the application access configuration page of site administration. We saw this earlier in site management under the product access tab. If you add a group to the Jira administration section of this page, it will automatically appear in the list of groups for the administer Jira global permission. Jira also adds the system administrators and Atlassian add-ons admin groups to this list. These are basically internal groups managed by Jira. Notice that the only group that currently does not have the administer Jira global permission is the Jira software users group. We have seen that new users are added to this group by default. Let's compare the list of groups with administer Jira global permission to the list with browse users and groups permission. All of the groups that can administer Jira can also browse users and groups. In addition, members of the Jira software users group can browse users and groups. This enables team members to select from other users and groups when using the application. If for some reason we did not want members of this group to have this permission, we can click the delete link associated with the group. Notice that our new external group that we created earlier is not in this list. New groups are not given this permission unless you explicitly add it. To add a global permission to a group, you scroll down to the Add Permission heading. You then select the permission that you want to add. In our case, we want to add Browse users and groups for our new external group. Notice that administered Jira is not in this list. This is because that permission is managed using the site administration as previously mentioned. In the group drop down, notice that the first option is anyone. If you select this, users in any group will have the associated global permission. We will select our new external group to provide it the browse users and groups permission. Now you can see that the external group has Browse users and groups global permission. Next, we will discuss next-generation project permissions. So far, we have discussed access and permissions that apply sitewide and at the Jira application level. Project permission specify what a user can see and do in a particular project. When talking about project permissions, it's useful to differentiate next-generation project permissions from classic project permissions. Classic project permissions are in general more flexible and powerful than next-generation project permissions, which are designed with simplicity in mind. Next-generation projects allow you to specify one of three access settings for the project, which we will see in a moment. These three options are good enough for a large percentage of projects. The permissions for classic projects are specified by a Jira administrator. This allows your organization to use common permission strategies for all projects. The permissions on these projects can be finally tuned to what your organization needs. To access setting for a next generation project is set by a project administrator. This allows each team to control their projects permissions. When you create a next-generation project, you must specify the projects access. There are three simple options. Open allows anyone with access to your site to create and edit issues in the project. This means that the project team members don't have to be separately added to the project because they already have access. Limited means that anyone with access to your site can view and comment on issues, but they cannot create and edit issues. Team members that need to create and edit issues must be added to the project. Private means that only people who have been added to the project can see the project. This is a way to prevent the project's issues from being widely visible in your organization. If you want to change the access after creating a next-generation project, you can navigate to Project Settings details and use the access drop down to change the access. To add team members to a project, you click on Project Settings and then the People tab, you then click the Add People button. You can add individual users or groups. When adding a person to a project, you must choose a project role for the user. Each role enables different functionality in Jira. Specifying the administrator role for a user means that they are a project administrator. This user will see the Project Settings tab and can make changes to the settings of the project. The member role is assigned to the typical member of the project. This user does not see the Project Settings tab, but they can view, add, and edit issues. The viewer role is the most limited. These users can view and comment on issues in the project, but not much else. If the project has open access, you will see an entry on the People page of the project saying that anyone with access to the site has a role of member. You do not need to specifically add members to this project. Also adding a person or group with a role of viewer would not make sense because all users already have a role of member, and therefore the user's member role would enable them to add and edit issues. Adding a viewer role for users or groups would have no effect because if a user is assigned multiple roles in a project, the most permissive role wins. If the access for a project is set to limited, you will see an entry on the projects people page that specifies that anyone with access to the site has a role of viewer. This means that if you want a user to be able to add and edit issues, you must click add people, add the user or group, and assign them a role of member. Also it would not make sense to add a user or group to this project and specify a role of viewer because all users of the site are already viewers in this project. If a project's access is set to Private, it means that none of the users of the site can see, add, or edit issues of the project unless they are added to the project's People page. For example, if you want a user or a group to be able to only view and comment on issues of the project, you'd add them with the role of viewer. You can view the Jira documentation to see the project and issue permissions for each role. For example, only users with the administer role can view and change project settings. As another example, users with the role of viewer cannot create and edit issues. Next, we will discuss an overview of Classic project permissions. The classic project permission model contains multiple abstractions, so there's more to learn than with next generation project permissions. The abstractions in the classic model are done for flexibility, and to avoid hard coding user and group names which would quickly become unmanageable. The classic project permissions model allows you to use custom permissions related policies in your account, possibly modifying your policies over time. The project role names for classic projects are slightly different than the next generation project role names that we saw earlier. Jira classic projects have two main built-in project roles. The first is the administrators role which is analogous to the administrator next generation role. This role is assigned to project administrators, and grant them the administer projects project permission. The other main project role is developers. These are the team members who do the work of the project. This is analogous to the member role in next generation projects. In addition to the built-in roles, Classic project roles can be created You assign project rolls under the people tab of a project's settings. Here we clicked the add button to add our test user to a project. We could also add groups to the project. You can see that here we must choose between the two main default project roles that we discussed earlier. Project roles are a Jira application level entity. Here we are in Jira settings, we select the system tab, and then project roles. Here are the default project roles; we see the administrators and developers project roles that we just discussed. There's also a role related to providing project permissions to add-ons This enables products that extend Jira to have permissions to do their work. Notice that each project role has an associated manage default members link. When you create a project, Jira automatically will assign any default members to the project role. The default members can be users and/or groups. Notice that you can add project roles. You do this when you want to grant project permissions to certain users for a specific set of functionality that is not granted in other roles. For example you might add a stake holders project role that allows stakeholders to view but not change the issues of the project. A permission scheme is used to grant a set of project permissions for a project. The permission scheme is what enables flexible fine grained permission control. A single permission scheme can be shared by multiple projects. Here's an example of a simplified permission scheme for a classic project named project A. The administer projects, project permission is granted to any user with the administrators role. In other words any member of the project who has been assigned the role of administrators is assigned the administer projects permission. To delete issues, project permission is also granted to the administrators role. What this means is that normal users who have not been assigned the administrators role for the project cannot administer the project or delete it's issues. To view the permission scheme used for a project, navigate to project settings, and click the permissions tab. This is the permission scheme for project A. You can see that this project is using the default software scheme. This is the permission scheme that will be used by default for all classic Jira software projects. Using project roles in the permission scheme means that the permission scheme can be re-used for multiple projects, this is because there are no hard-coded users or groups The project permissions are divided into categories with the first category also called project permissions. You can see that the administer projects' project permission is assigned to two project roles. The first is the administrators role which is for project administrators. The second is the add-on role that we talked about earlier. If you look at the browse projects' project permission, you can see that it is assigned to any logged in user. Any logged in user is allowed to see this project, and the issues within it. This is a key thing to realize about the default permission scheme used in Jira. It has an open approach to accessing the projects and issues in the account because the browse projects, project permission has been granted to any user with Jira access, all users can see this project as well as browse the issues within it. If for whatever reason your organization doesn't want to provide that much access to the project, if you are a Jira administrator, you can copy the default software scheme, and modify it for your needs. You would then assign your newly created permission scheme to the project. A user who is granted the administer projects' project permission, is known as a project administrator. In the Jira user interface, a project administrator can do more than a typical team member. These capabilities are built into the Jira application, and are available to project administrators because they had been granted the administer projects permission for the project. They can manage the members of the project, they can manage components which are a way to group a subset of issues in a project, they can manage versions, edit some project details such as the project name and description, create boards, and define issue level security which allows them to increase the security of issues in the project. We have seen that users who are assigned the administrators role are granted the administer projects permission, our project administrators, and can perform the tasks just mentioned. In addition, the default permission scheme grants users in the administrator's role the following capabilities: Users assigned the administrators project role can delete issues, modify reporters which means that they can change the user who created the issue, manage watchers, which means that they can change which users are notified when issues change, they can edit and delete comments related to an issue. A normal user can only edit or delete their own comments, they can delete attachments that users made to the issue, and they can edit or delete work logs which allow users to log their time spent on an issue. This is just the default behavior. You can create a permission scheme for your project or set of projects that customizes these permissions in a way that works for you. Here's a review of what we've discussed in this video: Jira global permissions apply to all projects, and are granted to users and groups. Next generation projects have a simple permission model with access levels of open, limited or private. Classic projects have a flexible permission model, with project permissions granted using permission schemes. Project roles enables certain product functionality for its members.
