Managing project permissions
The following table lists the different types of project permissions and the functions they secure. Note that project permissions can also be used in workflow conditions.
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, and some project details ('Project Name', 'URL', 'Project Lead', 'Project Description'). |
| Extended project administration | Gives the project administrator the ability to edit workflows and screens under certain conditions. |
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:
Depending on the complexity of your board's filter query, you may need further consideration when configuring the 'Manage Sprints' permission for users. For more information on the impact of complex filters, and ways to simplify your filter query, see Using Manage Sprints permission for advanced cases.
|
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 autocompletion of users in the Assign Issue dropdown. (See also Assignable User permission below) |
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-tasks 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 Create Issue permission. |
Resolve issues | Permission to resolve and reopen issues based on the workflow condition. This also includes the ability to set the 'Fix For version' field for issues. Requires the Transition issues permission. Also see the 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. create 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. |
Permission schemes
What is a permission scheme?
A permission scheme is a set of user/group/role assignments for the project permissions listed above. Every project has a permission scheme. One permission scheme can be associated with multiple projects.
Why permission schemes?
In many organizations, multiple projects have the same needs regarding access rights. (For example, only the specified project team may be authorized to assign and work on issues).
Permission schemes prevent having to set up permissions individually for every project. Once a permission scheme is set up it can be applied to all projects that have the same type of access requirements.
Creating a permission scheme
- Choose
> Issues. - Select Permission Schemes to open the Permission Schemes page, which displays a list of all permission schemes in your JIRA system and the projects that use each scheme.
- Click the 'Add Permission Scheme' link.
- In the 'Add Permission Scheme' form, enter a name for the scheme, and a short description of the scheme. Select Add.
- You will return to the 'Permission Schemes' page which now contains the newly added scheme.
Adding users, groups, or roles to a permission scheme
- Choose > Issues.
- Select Permission Schemes to open the Permission Schemes page, which displays a list of all permission schemes in your JIRA system and the projects that use each scheme.
- Locate the permission scheme you would like to update, and select Permissions in the Operations column to view the scheme.
- Select the 'Edit' link for the permission you wish to add to, this displays the 'Grant permission' dialog.
- Select who to add the selected permission to, and click the 'Grant' button. The users/groups/roles will now be added to the selected permission. Note that project roles are useful for defining specific team members for each project. Referencing project roles (rather than users or groups) in your permissions can help you minimize the number of permission schemes in your system.
- Repeat the last 2 steps until all required users/groups/roles have been added to the permissions.
Deleting users, groups, or roles from a permission scheme
- Choose > Issues.
- Select Permission Schemes to open the Permission Schemes page, which displays a list of all permission schemes in your JIRA system and the projects that use each scheme.
- Locate the permission scheme of interest and click its name to show the list of 'Project Permissions' (above).
- Click the Remove link for the permission you wish to remove the users, groups, or roles from.
Select the users, groups, or roles you wish to remove, and click the Remove button.
Associating a permission scheme with a project
- Choose
> Projects, and select the relevant project. - Select the project of interest to open the Project Summary administration page for that project. See Defining a project for more information.
- On the lower right, in the Permissions section, click the name of the current scheme (e.g. 'Default Permission Scheme') to display the details of the project's current permission scheme.
- Click the 'Actions' dropdown menu and choose 'Use a different scheme'.
- On the 'Associate Permission Scheme to Project' page, which lists all available permission schemes, select the permission scheme you want to associate with the project.
- Click the 'Associate' button to associate the project with the permission scheme.
Deleting a permission scheme
- Choose > Issues.
- Select Permission Schemes to open the Permission Schemes page, which displays a list of all permission schemes in your JIRA system and the projects that use each scheme.
- Click the Delete link (in the Operations column) for the scheme that you want to delete.
- A confirmation screen will appear. To delete click Delete otherwise click Cancel.
- The scheme will be deleted and all associated projects will be automatically associated with the Default Permission Scheme. (Note that you cannot delete the Default Permission Scheme.)
Copying a permission scheme
- Choose > Issues.
- Select Permission Schemes to open the Permission Schemes page, which displays a list of all permission schemes in your JIRA system and the projects that use each scheme.
- Click the Copy link (in the Operations column) for the scheme that you want to copy.
- A new scheme will be created with the same permissions and the same users/groups/roles assigned to them.