Custom field permissions are created within Field Configuration Schemes, which are then assigned to specific projects.
Project permissions are able to be granted based on:
- Individual users
- Groups
- Project roles
- Issue roles such as 'Reporter', 'Project Lead' and 'Current Assignee'
- 'Anyone' (e.g. to allow anonymous access)
- A (multi-)user picker custom field.
- A (multi-)group picker custom field. This can either be an actual group picker custom field, or a (multi-)select-list whose values are group names.
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.
Issue Permissions | Explanation |
|---|---|
View Restrictions | Permission to assign issues to users. Also allows autocompletion of users in the Assign Issue dropdown. (See also Assignable User permission below) |
Edut Restrictions | Permission to be assigned issues. (Note that this does not include the ability to assign issues; see Assign Issue permission above). |
History View Restrictions | Permission to close issues. (This permission is useful where, for example, developers resolve issues and testers close them). 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). Note that all edits are recorded in the Issue Change History for audit purposes. |
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. This also includes the ability to set the 'Fix For version' field for issues. 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 Issue 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. |