Documentation for JIRA 6.3 EAP developer (EAP) releases only. Not using this? See below:
(JIRA 6.2.x documentation | JIRA OnDemand documentation | earlier versions of JIRA)

Skip to end of metadata
Go to start of metadata

Project permissions are created within Permission 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.

On this page:

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').

Browse Projects

Permission to browse projects, use the Issue Navigator and view individual issues (except issues that have been restricted via Issue 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.

View Development Tools

Permission to view the Development panel, which displays information from Bitbucket, GitHub, Stash, FishEye, Crucible and Bamboo, if JIRA is integrated with compatible versions of these applications.

For older versions of Stash and FishEye or for Subversion and CVS, this grants permission to view the related source code commits for an issue, in the 'Commits' and 'Source' tabs. Note that for CVS, to view the related source code commits, the project needs to be associated with at least one Repository.

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. (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.

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 organisations, multiple projects have the same needs regarding access rights. (For example, only the specified project team may be authorised 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

  1. Log in as a user with the 'JIRA Administrators' global permission.
  2. 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.
    (tick) Keyboard shortcut: 'g' + 'g' + start typing 'permission schemes'
  3. Click the 'Add Permission Scheme' link.
  4. In the 'Add Permission Scheme' form, enter a name for the scheme, and a short description of the scheme. Click the 'Add' button.
    Screenshot: The 'Add Permission Scheme' form
  5. You will return to the 'Permission Schemes' page which now contains the newly added scheme.

Adding Users, Groups or Roles to a Permission Scheme

  1. Log in as a user with the 'JIRA Administrators' global permission.
  2. 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.
    (tick) Keyboard shortcut: 'g' + 'g' + start typing 'permission schemes'
  3. Locate the permission scheme of interest and click its name (or click the 'Permissions' link in the 'Operations' column) to show a list of permissions.
    Screenshot: Project Permissions
  4. Click the 'Add' link in the 'Operations' column, which displays the 'Add Permission' page.
  5. After selecting one or more permissions to add and who to add the selected permissions to, click the 'Add' button. The users/groups/roles will now be added to the selected permissions. 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 minimise the number of permission schemes in your system.
    Screenshot: Add Users To Permissions
  6. 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

  1. Log in as a user with the JIRA Administrators global permission.
  2. 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.
    (tick) Keyboard shortcut: g + g + start typing permission schemes
  3. Locate the permission scheme of interest and click its name (or click the Permissions link in the 'Operations' column) to show the list of 'Project Permissions' (above).
  4. Click the Delete link in the "Users / Groups / Roles" column next to the name of the user, group or project role you wish to delete.

Associating a Permission Scheme with a Project

  1. Log in as a user with the JIRA Administrators global permission.
  2. Choose > Projects.
    (tick) Keyboard shortcut: g + g + start typing projects
  3. Select the project of interest to open the Project Summary administration page for that project. See Defining a Project for more information.
  4. 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.
  5. Click the 'Actions' dropdown menu and choose 'Use a different scheme'.
  6. 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.
  7. Click the 'Associate' button to associate the project with the permission scheme.

Deleting a Permission Scheme

  1. Log in as a user with the JIRA Administrators global permission.
  2. 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.
    (tick) Keyboard shortcut: g + g + start typing permission schemes
  3. Click the Delete link (in the Operations column) for the scheme that you want to delete.
  4. A confirmation screen will appear. To delete click Delete otherwise click Cancel.
  5. 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.)

(info) See also Minimising the number of Permission Schemes and Notification Schemes.

Copying a Permission Scheme

  1. Log in as a user with the JIRA Administratorsglobal permission.
  2. 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.
    (tick)Keyboard shortcut: g + g + start typing permission schemes
  3. Click the Copy link (in the Operations column) for the scheme that you want to copy.
  4. A new scheme will be created with the same permissions and the same users/groups/roles assigned to them.

Global Permissions

This table lists the different global permissions and the functions they secure:

Global Permission

Explanation

JIRA System Administrators

Permission to perform all JIRA administration functions.
(warning) The number of users that count towards your JIRA license is the sum of all users (including users in groups) that have the JIRA System Administrators permission, even if they do not also have the JIRA Administrators or JIRA Users permissions. A user with JIRA System Administrators will be able to log in to JIRA without the JIRA Users permission, but may not be able to perform all regular user functions (e.g. edit their profile) unless they also belong to a group that has the JIRA Users permission.

JIRA Administrators

Permission to perform most JIRA administration functions (see list of exclusions below).
(warning) The number of users that count towards your JIRA license is the sum of all users (including users in groups) that have the JIRA Administrators permission, even if they do not also have the JIRA System Administrators or JIRA Users permissions. A user with JIRA Administrators will be able to log in to JIRA without the JIRA Users permission, but may not be able to perform all regular user functions (e.g. edit their profile) unless they also belong to a group that has the JIRA Users permission.

JIRA Users

Permission to log in to JIRA.
(warning)  The number of users that count towards your JIRA license is the sum of all users (including users in groups) that have this permission. If you want to reduce this count, see Updating your JIRA License Details.
(info) Granting the JIRA Users permission to a group results in all newly created users being automatically added to that group. The exception to this are groups that also have either the JIRA System Administrators or JIRA Administrators permissions, since JIRA prevents groups with these administrative-level global permissions from being granted the JIRA Users permission. Furthermore, it would be unwise to automatically grant these administrative-level global permissions to all new users.

Browse Users

Permission to view a list of all JIRA user names and group names. Used for selecting users/groups in popup screens. Enables auto-completion of user names in most 'User Picker' menus and popups.

Note that the Assign User permissions also allows a limited version of this on a per-project basis.

Create Shared Objects

Manage Group Filter Subscriptions

Permission to manage (create and delete) group filter subscriptions.

Bulk Change

Permission to execute the bulk operations within JIRA:
- Bulk Edit *
- Bulk Move *
- Bulk Workflow Transition
- Bulk Delete *
( * subject to project-specific permissions.)

(warning) The decision to grant the Bulk Change permission should be considered carefully. This permission grants users the ability to modify a collection of issues at once. For example, in JIRA installations configured to run in Public mode (i.e. anybody can sign up and create issues), a user with the Bulk Change global permission and the Add Comments project permission could comment on all accessible issues. Undoing such modifications may not be possible through the JIRA application interface and may require changes made directly against the database (which is not recommended).

43 Comments

  1. Anonymous

    Can we have a diagram similar to the excellent diagram showing the relationship between screen, fields, workflows and projects? 

  2. Anonymous

    I second that.

  3. Anonymous

    I'd be great is it was possible to add multiple project roles or groups at a time per permission. It would save quite some time when creating new permission scheme.

  4. Anonymous

    Users as developers are able to delete the other users from their group,  is it normal or its a problem

  5. Anonymous

    The new deployment of JIRA has the following click path for Permission Schemes:

    Select 'Administration' > 'Issues' > 'Misc. Schemes' > 'Permission Schemes'


    -- "awwww monkey nuts"

  6. Anonymous

     

    This whole section simply fails to explain something as simple as how to add a user and have users have access to only certain projects.  It is obscurely written and the diagram is critical.  Examples about how to do simple task administration are badly needed

    1. Hello there,

      I agree that this page could do with some tweaking and rearranging (which will be done when time permits).

      However, have you seen the overview about configuring security in JIRA on the parent Configuring Security page? The diagram on that page provides an overview of how to implement security (including permissions) in JIRA — from adding users to groups/project roles and then on to how to add these users/groups to project permissions (above). This diagram also links out to more detailed pages of the Administrator's Guide (like this page here).

      Cheers,

      Giles.

  7. Anonymous

    I have a problem with the assigning. If i create an issue, than i can only assign the admin and the owner. I seted the assign and assignable permissions to all users but int the drop down list nothing changed.

    Assign Issues
    Ability to assign issues to other people.
    • Project Role (Developers)
    • Group (jira-users)
    • Group (Testers)
    Assignable User
    Users with this permission may be assigned to issues.
    • Project Role (Developers)
    • Group (jira-users)
    • Group (Testers)
  8. Anonymous

    Can't I as a Project Lead and Project Administrator modify the project's permission scheme? It seems you need global permission for that.

  9. Anonymous

    One option that I'm very surprised doesn't seem to exist is the ability to allow Watchers to view tickets.  We have a project that only a select group of people my access or even view, for security reasons.  However, one side-effect of this is that even though someone outside that group may have a business interest in a specific ticket, and so I set that person up as a watcher on said ticket, they still cannot view the ticket at all because they do not have Browse Project permissions.  I cannot give that permission to everyone in the company, and I don't want to give that permission to the individual, as that would allow him to see tickets he should not be able to access.  I'd like to be able to add 'Watchers' to the Browse Project permission, so that a person listed as a watcher on a ticket could view that ticket, without having access to the rest of the tickets in the project.

     

    Is there a way to do this that I'm not seeing?  Is there a plug-in that can make this happen?  If the answer to those two questions is 'no', I'd like to make this an official feature request.

     

    1. Anonymous

      I would also like this very much!!!!  Is this a feature request yet?

    2. Anonymous

      I'd like an answer to this as well.

    3. Anonymous

      I'd definitely vote for this!

  10. Anonymous

    how can we change project under edit, as many a times a bug is posted on the incorrect project. The field should be enabled.

  11. Anonymous

    There is no Actions dropdown menu - man, you guys make this way to complex - who does the UX on JIRA?  They suck at it.

     

  12. Is there a way to set up more precise permissions in regards to moving issues.  

    Specifically:

    We set up a six stage Kanban board with Backlog and Ready as the first two statuses.  I am okay with all of the developers being able to move an issue through the workflow from stage to to stage once it is in Ready, but I want to limit permissions so only the PM can move from Backlog to Ready.  Is there a way to set this up while stil maintaining the ability of the developers to create tasks?

    1. I'm curious about this too.  Did you get an answer on how to control custom status transitions?

  13. Anonymous

    Can we restore default permission settings?

  14. Anonymous

    I'm trying to change a project's permission scheme from an external program (through a REST interface) to put/remove from 'on hold' status. Are there API functions that will allow me to do this in a plugin?

  15. Anonymous

    I'm trying to filter on the assignee in the issue list as a standard user, but I can not select any user.I can only select current user and unassigned. Is this a bug? I'm using JIRA V6.0.

  16. Anonymous

    how one specified user can close an issue ,he is always in the group added in the close issue group.

  17. Does the Administer projects also let you change the Default Assignee?

  18. Anonymous

    is there any way i can add more than 1 project lead on a single project.

    1. Project leads are really just used as the default assignee and a handy place to record who is responsible for the product, often a PM role. You can't have multiple project leads but see Setup Multiple and Group Assignees In JIRA which may give you some ideas for workarounds such as having a JIRA user with a email distribution list as an email address. It's usually better practice to modify the notification scheme to send email to the people you would want for project leads.

  19. This documentation is not well written:  "...Project permissions can be granted to:..." is not the same thing as "Project permissions must be granted to:...". 

    What is the lowest mandatory configuration-setting(s) required to allow access to JIRA?

    1. "can be granted"  in the sense of "are able to be granted" seems ok to me.

      To access JIRA see Global Permissions and the JIRA Users permission

  20. Anonymous

    ... well, "are able to be granted" means that you have to option to do it or not to do it.  Some after reading it, you still do not know what is mandatory...

    1. That's correct. You have the option. This page is talking about project permissions. The mandatory part is in Global Permissions. If you want a user to have access to a particular project there are a number of ways to allow that. The most common one and default way is to use a project role Users that contains the jira-users group, and a permission scheme that grants the Browse Projects permission to the Users project role.

  21. Anonymous

    Hi all, please help:

     

    project = jiraproject AND assignee was in membersOf(jiragroup)

     

    does work for administrators, but not for "normal" users (error message: A value provided by the function 'membersOf' is invalid for the field 'assignee'.) Which rigths do a user need to execute this?

     

    Thanks

  22. Anonymous

    Hi. Permission for versions is ridiculous. Versions editing/adding is regular project activity but it requires administrative permissions! So all release managers, architects and senior developers should be administrators…

    1. I completely agree...is there any way around this poorly setup restriction?

  23. Jira's permissions management must take the price as the most convoluted permissions system in the history of software development. Even in Lotus Notes it was easier to manage permissions.

    I can appreciate the power in flexibility, but you guys need some kind of "Wizard mode" that allows an admin to get a new, isloated project up and running in a few minutes.

    1. No way. JIRA only has 30 different permissions and not even full field-level permissions. Take a look at  ExtraView (http://docs.extraview.com/site/extraview-80/administration-guide/site-configuration-menu/security-permissions) You can spend hours in that screen.

  24. Why is it allowed to make your own status but not to set permissions on it?

  25. Anonymous

    I am trying to allow the current assignee to close a subtask.  I have that added as an explicit permission on my project.  You cannot differentiate between an issue and subtask, from what I see.  I don't have certain transitions on the parent issue limited by user group....but subtasks I thought were distinct entities on their own.  What am I missing in my setup?

    1. Anonymous

      sorry, I DO have certain transitions on the parent limited by group.  (can't type)

  26. Hello - Is there a way to restrict the ability to create an Agile Board?   It looks like the ability is bundled in with the permissions to create other shared objects (like filters), but it would be great if we could restrict this function just to admins, but allow other users to create and share filters.

     

    Thanks!

      1. I guess you mean Quick Filters on the board, not the board filter itself. Yes, Quick Filters are one area of JIRA Agile board configuration that seems to get changed more than anything. 

  27. Hi Matt - No actually, I just meant can we restrict the ability to create an Agile board in general, so there aren't too many of them floating around.  I can restrict the ability to create quick filters on a board to the board Admins, but I don't seem to be able to restrict the ability to create a board in general.

    1. Ah, I see. Only users with the global permission Create Shared Objects can create boards, but unfortunately this is also what control sharing dashboards and filters. Still  you might be able to find a smaller group than jira-users for this?

      Creating a Board

      Create Shared Objects

      Ability to share dashboards and filters with other users, groups and roles.

  28. We have too many boards - many that are not in use. Limiting who can create will eliminate the mess.