robotsnoindex
robotsnoindex
descriptionGet the details on how access and permissions are defined in next-gen software projects, and what each permission allows people to do.

Three main settings determine a person's permissions in your next-gen project:

  1. Their product access.

  2. The project's access level.

  3. Their role in the project.

Site admins control who has access to use the Atlassian products their organization is subscribed to. Read more about managing users and application access across your Atlassian site.

You can't edit project permissions or roles on the Free plan for Jira Software or Jira Core, and you can't configure issue-level security on any Free plan (including Jira Service Desk). Find out more about how project permissions work in Free plans. To take advantage of Jira's powerful project permission management features, upgrade your plan.

Product access

For next-gen projects, a person needs product access to Jira Software to:

  • Become a member of next-gen software projects.

  • Create and administer their own next-gen software projects.

Site admins can grant users product access in their site administration settings. Learn more about updating product access.

Project access level

The project's access level gives any logged in Jira Software user a certain role in your project.

Next-gen software projects have three, simple access levels:

  • Open. When a project is open, anyone on your Jira site can view, create and edit issues in your project. With this access level, Jira gives anyone who logs into your Jira site the Member role in your project.

  • Limited. When a project is limited, anyone on your Jira site can view and comment on issues in your project. But, they can't edit them or create new ones. With this access level, Jira gives anyone who logs into your Jira site the Viewer role in your project.

  • Private. When a project is private, only Jira admins and people you add to the project can see it in their project directory or its issues in search results.

Jira administrators (anyone with the Administer Jira global permission) always have access to your project's settings. Read more about how people access your next-gen project.

Your project’s access level sets general permissions for people across you Jira site. You can give specific access or additional permissions to individual people by creating your own project roles. Read more about roles.

When you add someone to a role, remember that they also inherit the role permissions given by your project’s access level:

  • In Open projects, everyone on your Jira site is given the default Member role.

  • In Limited projects, everyone on your Jira site is given the default Viewer role.

  • In Private projects, only Jira admins and people you add to the project have a role.

Project permissions

Here’s a list of the permissions you can fine-tune in your next-gen software project by creating custom roles. Read more about roles.

Access development tools

This permission allows people to see linked code commits, reviews, and build information on any issue in your project if your Jira admin has connected a distributed version control system (DVCS) tool like Bitbucket or Github.

This permission requires product access to Jira Software. Learn more about giving people access to your Atlassian products.

Add attachments

This permission allows people to attach files to any issue in your project. Your Jira admin may limit what you can attach and how big your files can be.

This permission doesn’t product access to Jira Software. You may grant this permission to anyone logged in to your Jira site.

Typically, any team member or collaborator may need this permission to help describe their work. Learn more about attaching files and screenshots to issues.

Add comments

This permission allows people to comment on any issue in your project.

This permission doesn’t product access to Jira Software. You may grant this permission to anyone logged in to your Jira site.

Typically, any team member or collaborator needs this permission.

Add or remove issue watchers

This permission allows people to add or remove people from an issue’s watch list.

This permission requires product access to Jira Software. Learn more about giving people access to your Atlassian products.

Administer the project

This permission allows people access to your project’s settings.

They can:

  • edit other people’s access to the project

  • configure issue types and their fields

  • enable and disable agile features like the roadmap or sprints

  • delete the project and its issues outright

This permission doesn’t product access to Jira Software. Typically, system administrators need this permission to help you configure your software project. For that reason, they don't need product access and won't take a seat in your site’s plan.

Jira administrators (anyone with the Administer Jira global permission) always has access to your project's settings.

Assign any issue

This permission allows people to change the value of the Assignee field on any of your project’s issues.

This permission requires product access to Jira Software. Learn more about giving people access to your Atlassian products.

This permission allows team members to hand over tasks at different stages of the work.

What about the “assignable user” permission?

In classic software projects, Jira admins can control who can be assigned an issue using permission schemes. In next-gen projects, we’ve simplified our permissions sets. If you grant a role any of the permissions that appear under the Work on project issues set, anyone with that role can be assigned issues in the project.

Create issues

This permission allows people to create issues in your project.

This permission doesn’t product access to Jira Software. You may grant this permission to anyone logged in to your Jira site.

Open organizations can benefit from allowing anyone to create issues in your project. For example, they may find and report bugs when using your team’s products. Some teams may restrict this permission to the core members of a team to keep their backlog tidy. Organizations with strict compliance or security needs may allow only Scrum masters or other leaders to create issues for their team.

Collaborate on issues (a set of permissions)

This set of permissions is typically granted to team members who don’t play a central role in your project. Your team may involve them in answering questions to progress work on an issue. Depending on your organization, you might give these permissions to designers, technical writers, consultants, or other supporting roles.

Granting this permission set grants the following bundled permissions:

  • Add attachments

  • Add comments

  • Edit their own comments

  • Delete their own attachments

  • Delete their own comments

None of these permissions require product access to Jira Software. You may grant them to anyone logged in to your Jira site.

Delete any attachment

This permission allows people to remove any attachments added by anyone on any of your project’s issues.

This permission requires product access to Jira Software. Learn more about giving people access to your Atlassian products.

While some teams may reserve this permission for management roles, open organizations can benefit from granting this power to autonomous team members. For example, if the issue requires images from a designer to help describe the work, it might be beneficial for team members to keep attachments up to date, even if they aren’t the owner of the original attachment.

Delete any comment

This permission allows people to remove any comment added by anyone on any of your project’s issues. It’s a bit of a super power.

This permission requires product access to Jira Software. Learn more about giving people access to your Atlassian products.

For traceability and historical investigations, we recommend preserving all issue comments. They can help you trace how a project went, or how an interaction could be improved in the future. For that reason, you may reserve this permission for team leaders, human resource managers, or other management roles.

Delete any issue

This permission allows people to delete any issue in your project, including its associated field data, comments, and work log entries.

This permission requires product access to Jira Software. Learn more about giving people access to your Atlassian products.

This permission is typically reserved for team leaders or project management roles. We don’t recommend deleting issues as a practice. Changing an issue’s status to a done-category status is a much better way of clearing up unneeded issues. Changing an issue’s status notifies the issue’s reporter, assignee, and watchers of the action your team has taken on the task.

Delete any work log entry

This permission allows people to remove any work log entry added by anyone on any of your project’s issues.

This permission requires product access to Jira Software. Learn more about giving people access to your Atlassian products.

Typically, removing other people’s work log entries is a permission reserved for team leaders or other management roles.

Delete their own attachments

This permission allows people to remove any file or image they attached to any issue in your project.

This permission doesn’t product access to Jira Software. You may grant this permission to anyone logged in to your Jira site.

Typically, anyone who can attach files to an issue (by having the Add attachments permission) should be able to remove their own attachments. This practice can help clarify work where many versions of a file or image are uploaded throughout the course of working on the issue. Organizations with strict compliance or traceability requirements may consider restricting this permission to preserve an accurate historical record throughout an issue’s lifecycle.

Delete their own comments

This permission allows people to remove any comments they’ve added to any issue in your project.

This permission doesn’t product access to Jira Software. You may grant this permission to anyone logged in to your Jira site.

Typically, anyone who can comment on an issue (by having the Add comments permission) should be able to remove their own comments. This practice can help clarify work if people leave erroneous or inaccurate comments. Organizations with strict compliance or traceability requirements may consider restricting this permission to preserve an accurate historical record throughout an issue’s lifecycle.

Delete their own work log entries

This permission allows people to remove the time they logged, the time they estimated as remaining, and the description of any work log entry they added to any of your project’s issues.

This permission requires product access to Jira Software. Learn more about giving people access to your Atlassian products.

Typically, people who actively work and log time in your project need to delete their own work logs in case of data entry errors.

Edit any comment

This permission allows people to alter the content of any comment added by anyone on any of your project’s issues.

This permission requires product access to Jira Software. Learn more about giving people access to your Atlassian products.

Open organizations encourage teams to edit each other’s comments to correct minor problems like spelling errors or broken links, and generally keep the communication stream clean. Organizations with strict compliance or traceability requirements may reserve this permission for team leaders or project managers.

Edit any due date

This permission allows people to change the value of the default Due date field on any of your project’s issues.

This permission requires product access to Jira Software. Learn more about giving people access to your Atlassian products.

Organizations with strict compliance or traceability requirements may reserve this permission for team leaders or project managers.

This permission is similar to the Schedule Issues permission in classic projects.

Edit any issue

This permission allows people to alter the summary and description, and change the value of fields that aren’t restricted by another permission (like the Assign issues or Edit reporters permissions).

This permission requires product access to Jira Software. Learn more about giving people access to your Atlassian products.

Open organizations encourage teams to keep each other’s work up to date by adjusting fields when viewing tasks throughout the course of their work. The ability to clarify descriptions and update fields is especially handy for team members who may review tasks during shared rituals like standup meetings, planning meetings, board grooming sessions, or project kick-off meetings. Organizations with strict compliance or traceability requirements may reserve this permission for team leaders or project managers.

Edit any work log entry

This permission allows people to alter the time logged, time remaining, and description of any work log entry added by anyone on any of your project’s issues.

This permission requires product access to Jira Software. Learn more about giving people access to your Atlassian products.

Typically, adjusting other people’s work log entries is a permission reserved for team leaders or other management roles.

Edit reporters

This permission allows people to change the value of the default Reporter field on any of your project’s issues. The Reporter field is automatically set to the issue’s creator at the time the issue is made.

This permission requires product access to Jira Software. Learn more about giving people access to your Atlassian products.

Edit their own comments

This permission allows people to alter the content of any comments they’ve added to any issue in your project.

This permission doesn’t product access to Jira Software. You may grant this permission to anyone logged in to your Jira site.

Typically, anyone who can comment on an issue (by having the Add comments permission) should be able to adjust their own comments and correct minor problems like spelling errors or broken links. Organizations with strict compliance or traceability requirements may consider restricting this permission to keep an accurate historical record throughout the course of an issue’s lifecycle.

Edit their own work log entries

This permission allows people to alter the time they logged, the time they estimated as remaining, and the description of any work log entry they added to any of your project’s issues.

This permission requires product access to Jira Software. Learn more about giving people access to your Atlassian products.

Typically, people who actively work and log time in your project will need to adjust their own work logs in case of data entry errors or changes to the work’s scope or requirements.

Link any issue

This permission allows people to link issues in your project to one another, or to issues in other projects on your site. To view the link properly, they need the same permission in the target project or service desk.

This permission requires product access to Jira Software. Learn more about giving people access to your Atlassian products.

Log work on any issue

This permission allows people to interact with the time tracking field on any of your project’s issues.

This permission requires product access to Jira Software. Learn more about giving people access to your Atlassian products.

This permission allows people to create a work log entry, where they can indicate the time spent and time remaining to complete the task, including a brief description of the work they did along the way.

This permission is called Work On Issues in classic projects.

Manage project issues (a set of permissions)

This set of permissions is typically granted to team leaders, project managers, Scrum masters, and other roles that generally oversee project work.

Granting this permission also grants the following bundled permissions:

  • Add or remove issue watchers

  • Edit any due date

  • Edit any comment

  • Edit any work log entry

  • Edit reporters

  • Delete any attachment

  • Delete any comment

  • Delete any issue

  • Delete any work log entry

Any of these permissions require product access to Jira Software. Learn more about giving people access to your Atlassian products.

Manage project sprints

This permission allows people to create, start, and complete sprints in your project. This includes adjusting the sprint duration and goal.

This permission requires product access to Jira Software. Learn more about giving people access to your Atlassian products.

Sprints are a concept from agile methodology, specifically a way of working called Scrum. Typically, sprints are managed by team leaders or designated Scrum masters.

Learn more about sprints, Scrum, and how to practice agile methods in Jira Software.

Move any issue

This permission allows people to move an issue to another project or service desk on your Jira site. To successfully move an issue, they also need permission to create issues in the target project or service desk.

This permission requires product access to Jira Software. Learn more about giving people access to your Atlassian products.

Transition any issue

This permission allows people to view any issue’s underlying workflow and update the status of any of your project’s issues. They can move any issue through the workflow, triggering any board rules that may be associated with the transition along the way. They can also resolve and close any issues in your project.

This permission requires product access to Jira Software. Learn more about giving people access to your Atlassian products.

This permission is a combination of the Transition Issues, Resolve Issues, and Close Issues permissions in classic projects.

View watchers

This permission allows people to see who’s watching any issue in your project.

This permission doesn’t product access to Jira Software. You may grant this permission to anyone logged in to your Jira site.

Work on project issues (a set of permissions)

This set of permissions is typically granted to developers, product managers, designers, quality assurance engineers, and others directly working to accomplish your project’s goals. Typically, these permissions are meant for who you might consider members of the core team.

Granting this permission also grants the following bundled permissions:

  • Assign any issue

  • Edit any issue

  • Edit their own work log entries

  • Delete their own work log entries

  • Link any issue

  • Log work on any issue

  • Transition any issue

Any of these permissions require product access to Jira Software. Learn more about giving people access to your Atlassian products.