Atlassian Jira Administrator ACP-100 – Introduction and the Jira Atmosphere Part 6

21. How to Set Groups and Application Access

Groups act as global containers designed to store and categorize a collection of users. With Groups, you can grant users functionality such as global permissions or application access. Let’s talk about the default groups in Jira. Depending on the applications you have installed, you may have two or more default groups in Jira.

Each Jira application automatically creates a group for itself when you install it and assign that group as the default. Default groups allow you to create users and automatically assign them to whichever group you select as the application’s default. Remember, Groups not only provide application access, but also grant global permissions, which you can change if you don’t want the automatic assignments. Let’s talk about each possible default group. First. There are Jira administrators. This is the admin group provided when you install Jira.

This group gets the Jira System Administrators and Jira Administrators global permissions automatically, as well as four other permissions. And this group won’t get automatically assigned to any application as the default. Next is Jira core users. This is the default group for Jira core application access, then Jira software users the default for software application access and Jira Service Desk users, which is the default for Jira Service Desk application access.

All three of these groups have the four no administrative global permissions automatically. For more information on Jira applications, check out our video on Jira Applications. You can also create your own groups in Jira, or groups that come from an external repository, such as LDAP. For example, violet needs to update the groups in the Great Adventure Jira instance. Adding a Developers Group and removing some existing members from the Finance Group.

Before we go into detail, let’s quickly revisit how to add a group in Jira. And for a full demo of this step, check out the Global Permissions video. First, we’ll head to the Groups page. We’re going to create a Developers Group, and now we see the new Developers group on our Groups page. Now that there’s a brand new group for developers, violet can remove some development staff from the Finance Group.

Let’s see how she does it. Navigate to the group’s page. When there, locate the group you want to edit and click Edit Members. We need to edit the finance group on the bulk edit group members page. Under group members, click to select a user, then click Remove Selected Users and you can control, click or command. Click on a mac. To select multiple users.

We select Eliza Wong, Jamal Meadows and Liberty Sloan. There’s no messaging. Once you click to remove a user, the user is just removed from the group. When you’re finished, go back to Groups and you should see the user count for the group lowered. Since Jira seven atlas Sian switched to an application based model, which means that users only consume a license for an application if they’re granted access to use that particular application. You can use a different group structure to share application access. However, when you upgrade your Jira instance any custom group to application mapping overwrites evaluate the need for sharing application access with all Jira Administrators. As a Jira admin, you can alter any piece of a project, so you may want to use caution in giving several users this ability. We recommend that you only grant admin permissions to trustworthy employees, but then allow these individuals application access for everything. A different strategy is to create personal and admin accounts for each administrator.

With limited access to the different applications, you can decide what’s best for your organization. But the reason we don’t recommend the second strategy is twofold users with Jira administrator permissions can grant themselves access to an application, so you can’t truly lock out Jira Administrators anyway. Also, users with two accounts take up the licenses needed for their standard account, as well as any licenses needed for their admin account. Do you plan to restrict administrator access to your Jira applications?

Navigate to the application access page. When there, scroll to the application where you want to add a group. We scroll to Jira Software so we can add the developers group. In the Select Group menu, select the group you want to grant access to, and we select the newly created Developers Group. Once you select the new group, you should see that group listed for the application and notice that the default group is the application group created when the application is first installed. In our example, that group is Jira Software users.

22. How to Create Project Roles

Project roles act as global categories used to define common functions in the teams and then associate those functions and projects. You can create and use project roles to grant permissions to collections of users through the permissions scheme associated with the project. If you need a recap on project level permissions, refer to the Jira Permissions Quick Guide. You can use project roles and permission schemes to manage notifications and notification schemes and to share filters, among other areas of Jira. You mainly use project roles and permission schemes and notification schemes as a way to easily manage who receives specific permissions and who receives certain notifications.

You can set the default role membership, but this is a global setting and affects every project created going forward, though it is not retroactive, project roles are global and you should keep names generic and intuitive since they are seen in every project. If you create a new role in the system, this role becomes visible in all projects past or present. In addition to default roles, which we will talk about in another video, and custom roles which you create as the Jira administrator.

There are a couple of additional administrator roles we discuss in this video board and Project Administrators in addition to the project roles, Jira software includes some specific board and Sprint permissions for managing software boards. In projects, the role for managing boards is called the board administrator. The permissions for a board administrator are not handled in a permission scheme. In fact, you either have board administrator access in a software project or you don’t.

By default, the person who creates the board becomes the board’s administrator. In many cases, that person is the Jira administrator who created the project. However, if you create your own board, you become the board administrator. Only administrator of a board can update the board administrators, so that needs to be part of your setup as a juradministrator. When you create a software project for a team, you need to capture what team members need to be board administrators. We talk more about Jira Software and Jira Software server for beginners as well as the scrum and canvas software courses. The project administrator role is a default that allows you to delegate project administrator functions to a user. Essentially, you put the designated project owner in charge of their own project. The Extended Project Administration option is enabled by default, so you should review and deselect this checkbox if you don’t want a permission scheme to include this permission.

These permissions allow project admins to have limited ability to edit workloads and screens that are not shared in Jira. For more information on project administrator permissions, check out the Jira Server for Power Users course. And to learn more about default roles in Jira, check out our video on Default Roles and Auditing. Include the Jira Administrators group in each permission scheme for the administer project’s permission. This option allows you to have a backup in case the project administrator is outsick and something in the project needs changing.

Assign groups to roles in a project as needed to sort access quickly for several users, you can allow project administrators to map the groups to project roles. Instead of directly mapping users to a project role as the Jira administrator, you can assign the project roles the appropriate permissions. Let’s check out how great Adventure uses project roles. Violet needs to create a new project role called QA. For grade adventure, navigate to the project Roles page. On the Project Role browser page, scroll to the Add Project Role section, add a name and description for your new project role, and then click Add Project Role. For example, we create a project role called QA.

Once you create a project role, it is available globally for your Project Administrators to use in their projects. We won’t cover adding members to a role, as that is a project administrator capability. However, it is best practice to use Project roles to manage settings like permissions and Jira, so make sure that your project admins know how they work.

23. How to Work with Default Roles and Auditing

Project roles allow you to create a bucket of users that you can then apply to permission schemes and elsewhere in Jira. In addition to creating project roles, you can set groups or users as default members of a project role. We recommend setting default members in some cases, as well as auditing your roles and groups as part of your task as a Jira administrator. Let’s talk about setting default roles. First, you can set default members of any in project role in Jira. For example, the administrator’s project role includes the Jira administrator group as default members. You may want to set a default member if you need to make sure a certain person or group always has access to complete the project roles function in your instance, once you create a project, Project Administrators can manage the actual membership, removing users or groups from roles as needed. Jira also includes some other default roles used in projects, but are not quite the same as project roles.

These include the default assignee for a project and the project lead. When you create a project, you can set the project lead for the project. The project administrator can update the default assignee as well as the membership of other roles used in the project. When working with a permission scheme, if you always want the project lead of a project to also be the project administrator, you can grant the project lead role the administrator project’s permission in the permission scheme at Great Adventure, Violet wants to set up Jira System Administrators as default members of the administrator’s role for all projects. This way, more people can jump in to help configure something in a project if the usual administrator is not available.

It also allows both Jira administrator groups access into projects to confirm settings are correct. To achieve this, Violet needs to set the Jira System Administrators group as a default group for the administrator’s project role. Let’s see how that’s done. Navigate to the project role browser. On the Project Role browser page, locate the role you want to update and click Manage default Members. We’re going to modify the administrator’s project role on the Edit Default Members for Project Role page. Under default groups click edit. Either type the name of the group you want to add or use the group picker to select a group. We use the group picker, select the Jira System Administrators group, and then click select to add the group to the box. Once you have your group selected, click Add to complete the default role membership.

Once you add a group to a project role, you can easily remove the group by selecting the checkbox next to the name of the group and then clicking Remove. You may need to temporarily add access to groups or update default membership at a later time. In fact, regularly reviewing who has access to which functions in Jira is a good practice. Let’s talk more about auditing groups. Next, we recommend that you periodically audit groups and roles to make sure you maintain the correct level of access in projects and globally across Jira. In most large organizations, this is enforced by an It security team to help with auditing. Jira includes an audit log that Jira system administrators can access. This log tracks all the configuration changes that users make inside of your Jira instance so that you can see for a particular change which user made the change and when they made it.

The audit log helps you see what action a user takes in the system. However, you can use the Permission Helper to see what permissions a specific user has in the system. We talk about the permission helper next. Check out our Jira Administrator reference guide for more tricks on auditing, group and role membership in Jira. The Permission Helper is a tool in Jira that allows you to see what permissions a user has for a specific issue in a project. We’re going to walk through using the permission helper to check out permissions for Maya Lopez for the Great Adventure Human Resources Project. We’re going to check permissions for Maya Lopez for an issue in the Great Adventure Human Resources Project.

And finally, we select the Delete Issues permission. To check the permission, we click Submit. On the Permission Helper page, we see information about the user and the permission as well as the permission scheme associated with the project for the issue you select. We also see a status for the permission in our example. Maya does not have the Delete issue permission for this project.