Handling Permissions in Jira

Table of content

Handling the Permission in Jira

Handling the Permission in Jira

Assigning the permissions to the particular user to manage, to control and to create a group and also includes administrating the jira account.

We can assign permission in two ways :

Providing permission within the project
Providing permission across different project

Permissions are created within the permissions scheme which is then assigned to the particular projects through the Administrator,

The permissions are differentiated based on the following :

Individual users
Groups
Project Roles

Project permissions overview:

Project permissions	Explanation
Administer projects	Permission to administer a project in Jira. This includes the ability to edit Project role membership, Project components, project versions.
Browse projects	Permission to browse projects, use the Issue Navigator and view individual issues (except issues that have been restricted via issue level security). Many other permissions are dependent on this permission, e.g. the Work On Issues permission is only effective for users who also have the 'Browse Projects' permission.
Manage sprints (only available to Jira Software users)	Permission to perform the following sprint-related actions for all projects in a board: Creating sprints Starting sprints Completing sprints Reopening sprints Reordering future sprints Deleting future sprints Editing sprint information (sprint name and dates) Moving the sprint footer Depending on the complexity of your board's filter query, you may need further consideration when configuring the Manage Sprints permission for users. In general, sprint actions require the Manage Sprints permission. However, there are some sprint actions (e.g. adding issues to sprints, removing issues from sprints) that require the Schedule Issues and Edit Issues permissions. When adding an issue to a sprint: Sub-tasks cannot be moved independently of their parents. An issue can only be assigned to one active sprint or future sprint. This means you can't add an issue to both an active sprint and a future sprint at the same time. You can add any issue to any active or future sprint, even if the issue doesn't match the filter query of the board where the sprint was created. When you do this: the issue is assigned to the sprint, but will not be visible on boards where the filter query excludes it. any sprint actions (e.g. start sprint, close sprint) that span multiple boards will also affect the sprint in all boards where the sprint is visible. if the issue doesn't match the filter query of any agile board, the issue will be linked to the sprint but not appear in any board. A sprint appears in any board — a single board or multiple boards — as long as the issues assigned to the sprint match the filter query of the board or boards. This also applies to completed sprints.
View development tools (only available to Jira Software users)	Permission to view the development panel, which provides you with just enough information to evaluate the status of an issue's development, at a glance.
View (read-only) workflow	Permission to view the project's read-only workflow when viewing an issue. This permission provides the View Workflow link against the Status field of the 'View Issue' page.
Issue permissions	Explanation
Assign issues	Permission to assign issues to users. Also allows auto-completion of users in the Assign Issue dropdown.
Assignable user	Permission to be assigned issues. (Note that this does not include the ability to assign issues, see Assign Issue permission above).
Close issues	Permission to close issues based on the workflow conditions. (This permission is useful where, for example, developers resolve issues and testers close them). Requires the Transition issue and Resolve issue transitions. Also, see the Resolve Issues permission.
Create issues	Permission to create issues in the project. (Note that the Create Attachments permission is required in order to create attachments.) Includes the ability to create sub-tasks (if sub-tasks are enabled)
Delete issues	Permission to delete issues. Think carefully about which groups or project roles you assign this permission to; usually it will only be given to administrators. Note that deleting an issue will delete all of its comments and attachments, even if the user does not have the Delete Comments or Delete Attachments permissions. However, the Delete Issues permission does not include the ability to delete individual comments or attachments.
Edit issues	Permission to edit issues (excluding the 'Due Date' field — see the Schedule Issues permission). Includes the ability to convert issues to Sub- task and vice versa (if sub-tasks are enabled). Note that the Delete Issue permission is required in order to delete issues. The Edit Issue permission is usually given to any groups or project roles who have the Create Issue permission (perhaps the only exception to this is if you give everyone the ability to create issues — it may not be appropriate to give everyone the ability to edit too).
Link issues	Permission to link issues together. (Only relevant if Issue Linking is enabled).
Modify reporter	Permission to modify the 'Reporter' of an issue. This allows a user to create issues 'on behalf of' someone else. This permission should generally only be granted to administrators.
Move issues	Permission to move issues from one project to another, or from one workflow to another workflow within the same project. Note that a user can only move issues to a project for which they have to Create Issue permission.
Resolve issues	Permission to resolve and reopen issues. This also includes the ability to set the 'Fix For version' field for issues. Requires the Transition issues permission. Also, see Close Issues permission.
Schedule issues	Permission to schedule an issue — that is, to edit the 'Due Date' of an issue. In older versions of Jira, this also controlled the permission to view the 'Due Date' of an issue.
Set issues security	Permission to set the security level on an issue to control who can access the issue. Only relevant if issue security has been enabled.
Transition issues	Permission to transition (change) the status of an issue.
Voters & watchers permissions	Explanation
Manage watcher list	Permission to manage (i.e. view/add/remove users to/from) the watcher list of an issue.
View voters and watchers	Permission to view the voter list and watcher list of an issue. Also, see the Manage Watcher List permission.
Comments permissions	Explanation
Add comments	Permission to add comments to issues. Note that this does not include the ability to edit or delete comments.
Delete all comments	Permission to delete any comments, regardless of who added them.
Delete own comments	Permission to delete comments that were added by the user.
Edit all comments	Permission to edit any comments, regardless of who added them.
Edit own comments	Permission to edit comments that were added by the user.
Attachments permissions	Explanation
Create attachments	Permission to attach files to an issue. (Only relevant if attachments are enabled). Note that this does not include the ability to delete attachments.
Delete all attachments	Permission to delete any attachments, regardless of who added them.
Delete own attachments	Permission to delete attachments that were added by the user.
Time-tracking Permissions	Explanation
Work on issues	Permission to log work against an issue i.e. creates a worklog entry. (Only relevant if Time tracking is enabled).
Delete all worklogs	Permission to delete any worklog entries, regardless of who added them. (Only relevant if time tracking is enabled). Also, see the Work On Issues permission.
Delete own worklogs	Permission to delete worklog entries that were added by the user. (Only relevant if time tracking is enabled). Also, see the Work On Issues permission.
Edit all worklogs	Permission to edit any worklog entries, regardless of who added them. (Only relevant if time tracking is enabled). Also, see the Work On Issues permission.
Edit own worklogs	Permission to edit worklog entries that were added by the user. (Only relevant if time tracking is enabled). Also, see the Work On Issues permission.

Information credit: confluence.atlassian.com

Permission scheme:

The Permission scheme is nothing but a set of groups, or user or An assignment for the project permissions, and multiple projects can be associated with one permission scheme.

Why we need a permission scheme

In big companies, many projects have the same type of requirement access, if we set up a permission scheme then instead of applying permission to each project individually, we can apply to all the projects which have the same type of access requirement.

Creating a Permission Scheme:

Let us see how to create a permission scheme

Select the Issues under the Jira settings and then select the permission schemes under Issues, it will display the Default permission scheme in your jira account.

Now, click on the Add Permissions Scheme and then enter the name which you want to create and then click on the Add button.
If you successfully created the new permission scheme then you will see the newly created scheme in the permission scheme page.

Adding Users, Roles, and Groups to a Permission Scheme:

Select the Issues under the Jira settings

And then select the permission scheme under the issues, once the permission scheme page displayed, it will display the current permission schemes.

Am going to update the customized software scheme, click on the Permissions under the Actions, in front of the customized software scheme.

Now the customized software scheme page will appear, select the Edit link in front of the permission you wish to add to. In the below image I selected the Administers projects and click Edit in front of the same.

Now, The Grant permission dialog box will display, select the administrator under the project role

And under the application access, select any logged in user

Next, under the Group, select the jira-software-users and then click on the Grant button

So, if you have successfully added the permission to the group then you will see the group name in front of the administers.

Associating a permission scheme with a project:

select the projects under the Jira software and then select the project you want to change the permission for, here I am selecting the Scrum demo project

Select the permissions under the project settings to display the current permission scheme, so it actually using the default software scheme.