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.
permission-scheme

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

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.

permission-scheme-action

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.

customized-software-scheme-page

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

grant-permission-project-role-administrator

And under the application access, select any logged in user

gp-application-access

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

gp-group-jira-software-users

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

successfully-added-group

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

scrum-demo-project-one

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

default-permission-settings

By clicking on the actions, select the use of a different

Comment / Suggestion Section
Point our Mistakes and Post Your Suggestions