Permission schemes, like other schemes such as notification schemes, are collections of associations between permissions and users or a collection of users. Each permission scheme is a reusable, self-contained entity that can be applied to one or more projects.
Like most schemes, permission schemes are applied at the project level. This allows you to apply fine-grained permissions for each project. Just like project roles, JIRA administrators oversee the creation and configuration of permission schemes, and it is up to each project's administrator to choose and decide which permission scheme to use. This way, administrators are encouraged to design their permissions that can be reused based on the common needs of an organization. With meaningful scheme names and descriptions, project administrators will be able to choose the scheme that will fit their needs the best instead of requesting a new set of permissions to be set up for each project.
We will first look at how JIRA administrators manage and configure permission schemes and then how project administrators can apply them in their projects.
Perform the following steps to start managing permission schemes:
On the Permission Schemes page, you will see a list of all the permission schemes. From here, you will be able to create new schemes, edit and delete existing schemes, as well as configure each scheme's permission settings.
Unlike other schemes, such as workflow schemes, JIRA does not create a project-specific permission scheme when you create a new project, but rather, it users a preconfigured scheme called Default Permission Scheme. This scheme is suitable for most simple software development projects. However, it is often not enough, and it is usually a good practice to not modify the Default Permission Scheme directly so that you can create your own permission schemes:
For new permission schemes, all of the permissions will have no permission configured. This means that if you start using your new scheme straight away, you will end up with a project that nobody can access. We will look at how to configure permissions in later sections of this chapter.
Just like most other schemes in JIRA, you need to further fine-tune your permission scheme to make it useful:
On this page, you will be presented with a list of project-level permissions, along with short descriptions for each, and the users, groups, and roles that are linked to each of the permissions. You will notice that for the Default Permission Scheme, most of the permission options have default users linked to them through project roles. If you are looking at a new permission scheme, there will be no users linked to any of the permissions. This is your one-page view of permission settings for projects, and you will also be able to add and delete users:
Like the notification schemes, JIRA offers you a range of options to specify which users should have certain permissions. You can specify users through some of the most common options such as groups, but you also have some advanced options, such as using users specified in a custom field.
Again, you have two options to grant permissions to a user. You can add them to specific permissions or multiple permissions at once. Both options will present you with the same interface and there is no difference between the two:
Permission options, such as User Custom Field Value, are a very flexible way to allow end users to control access. For example, you can have a custom field called Editors, and set up your Edit Issues permission to allow only users specified in the custom field to be able to edit issues.
The custom field does not have to be placed on the usual view/edit screens for the permission to be applied. For example, you can have the custom field appear on a workflow transition called Submit to Manager; once the user has selected the manager, only the manager will have permission to edit the issue.
You can easily revoke a permission given to a user, as follows:
When you are trying to revoke permissions to prevent users from gaining certain access, you need to make sure no other user options are granted the same permission that might be applied to the same user. For example, if you have both the Single User and Group options set for the Browse Projects permission, then you will need to make sure that you revoke the Single User option and also make sure that the user does not belong to the Group option selected, so you do not have a loophole in your security settings.
All this time, we have been saying how permission schemes can be selected by project managers to set permissions for their projects; now, we will look at how to apply the scheme to your projects. There really is nothing special, permission schemes are applied to projects in the same way as notification and workflow schemes:
Permission schemes are applied immediately, and you will be able to see the permissions take effect.