Having trouble creating a read-only user for JIRA

I wanted to create a read-only user for our on-demand JIRA (v7.0.9) in order to login as this user during our morning stand up meetings. This avoids anyone accidentally making changes during these meetings.

I attempted to create this read-only user as follows:

  1. Created a group named readers
  2. Added this group to Applications -> Application access
  3. Created a permissions scheme named Readers in Issues -> Permission schemes
  4. Assigned the following permission to this scheme: Browse Projects <Group (readers)>, View Read-Only Workflow<Group (readers)>, View Voters and Watchers<Group (readers)>
  5. Created the read-only user and added them to the new readers group
  6. Removed this new user from the jira-software-users group

Once I did this, I successfully logged-in as the new read-only user and navigated to the Active sprints view of our JIRA Board. This displayed all the stories / sub-tasks as expected. However, I was still able to move sub-tasks from one swim lane to another, edit sub-tasks, etc.

Have I missed some fundamental step here or is what I want just not possible at all in JIRA?

 

1 answer

This widget could not be displayed.

Check all the groups and roles this user has against the permission scheme - they're somehow getting the JIRA permissions for "transition" and "edit" on the issue in the project.  You have probably put them in a "can log in" group (so they can log in) and that group is in a role that allows for transition and edit.

Is there a way to easily see the effective permissions of a user?

As I indicated above I created this new user and have ensured that they belong to just the new group that I created named readers. I also created a new permissions scheme that has no edit rights at all. 

So how are they able to log in?

They are able to log in because of the first two steps I did above:

  1. Created a group named readers
  2. Added this group to Applications -> Application access


The second step is the one I believe that gives them login access.

When a new user is created they are automatically added to the jira-software-users group. I removed my read-only user from this group and then found that I had to add the readers group I had created to the Application access in order to allow them to login.

Bother, I'm really sorry, my brain skipped point 2 completely.

Could you give us the full list of roles/groups/etc who have "transition issue" permission in the permission scheme?

Sorry for the late reply but your system is not allowing me to post more than 3 comments in 24 hours since I am new sad - apparently I need to earn 3 points.

Here is the definition of the read-only user I created:

Full name

Username

Login details

Group name

Applications

Directory

 

smartboard

smartboard 
<obfuscated>

Count: 2
Last: Yesterday 10:57 PM

 

JIRA Internal Directory

Edit 

 

Here is how the Application access is setup:

Application access

 

Name

 

Default

 

jira-software-users(34 users)

 

 

 

Remove

readers (1 user)

 

 

 

Remove

site-admins (1 user)

 

ADMIN

 

Remove

 

 Here is how the readers group is setup:

 readers

Permission Schemes

Notification schemes

  • There are no Notification Schemes associated with this Group.

Issue Security Schemes

  • There are no Issue Security Schemes associated with this Group.

Saved Filters

  • There are no Saved Filters associated with this Group.

 

Here is how the Readers Permission Scheme is setup:

Edit Permissions — Readers

On this page you can edit the permissions for the "Readers" permission scheme.

Project Permissions

Users / Groups / Project Roles

Operations

Administer Projects

Ability to administer a project in JIRA.

 

Browse Projects

Ability to browse projects and the issues within them.

 

View Development Tools

Allows users in a software project to view development-related information on the issue, such as commits, reviews and build information.

 

View Read-Only Workflow

Users with this permission may view a read-only version of a workflow.

 

Issue Permissions

Users / Groups / Project Roles

Operations

Assignable User

Users with this permission may be assigned to issues.

 

Assign Issues

Ability to assign issues to other people.

 

Close Issues

Ability to close issues. Often useful where your developers resolve issues, and a QA department closes them.

 

Create Issues

Ability to create issues.

 

Delete Issues

Ability to delete issues.

 

Edit Issues

Ability to edit issues.

 

Link Issues

Ability to link issues together and create linked issues. Only useful if issue linking is turned on.

 

Modify Reporter

Ability to modify the reporter when creating or editing an issue.

 

Move Issues

Ability to move issues between projects or between workflows of the same project (if applicable). Note the user can only move issues to a project he or she has the create permission for.

 

Resolve Issues

Ability to resolve and reopen issues. This includes the ability to set a fix version.

 

Schedule Issues

Ability to view or edit an issue's due date.

 

Set Issue Security

Ability to set the level of security on an issue so that only people in that security level can see the issue.

 

Transition Issues

Ability to transition issues.

 

Voters & Watchers Permissions

Users / Groups / Project Roles

Operations

Manage Watchers

Ability to manage the watchers of an issue.

 

View Voters and Watchers

Ability to view the voters and watchers of an issue.

 

Comments Permissions

Users / Groups / Project Roles

Operations

Add Comments

Ability to comment on issues.

 

Delete All Comments

Ability to delete all comments made on issues.

 

Delete Own Comments

Ability to delete own comments made on issues.

 

Edit All Comments

Ability to edit all comments made on issues.

 

Edit Own Comments

Ability to edit own comments made on issues.

 

Attachments Permissions

Users / Groups / Project Roles

Operations

Create Attachments

Users with this permission may create attachments.

 

Delete All Attachments

Users with this permission may delete all attachments.

 

Delete Own Attachments

Users with this permission may delete own attachments.

 

Time Tracking Permissions

Users / Groups / Project Roles

Operations

Delete All Worklogs

Ability to delete all worklogs made on issues.

 

Delete Own Worklogs

Ability to delete own worklogs made on issues.

 

Edit All Worklogs

Ability to edit all worklogs made on issues.

 

Edit Own Worklogs

Ability to edit own worklogs made on issues.

 

Work On Issues

Ability to log work done against an issue. Only useful if Time Tracking is turned on.

 

 

Here are the full set of permissions I found for our main project in JIRA (via Project -> Administration -> Permissions screen):

Project Permissions

Permission

Users / Groups / Project Roles

Administer Projects
Ability to administer a project in JIRA.

  • Project Role (Administrators)
  • Project Role (atlassian-addons-project-access)
  • Group (BA's)

Browse Projects
Ability to browse projects and the issues within them.

  • Application Role (Any logged in user)
  • Project Role (atlassian-addons-project-access)

View Development Tools
Allows users in a software project to view development-related information on the issue, such as commits, reviews and build information.

  • Application Role (Any logged in user)
  • Project Role (atlassian-addons-project-access)

View Read-Only Workflow
Users with this permission may view a read-only version of a workflow.

  • Application Role (Any logged in user)
  • Project Role (atlassian-addons-project-access)
  • Group (jira-read-only)

Issue Permissions

Permission

Users / Groups / Project Roles

Assignable User
Users with this permission may be assigned to issues.

  • Application Role (Any logged in user)
  • Project Role (atlassian-addons-project-access)

Assign Issues
Ability to assign issues to other people.

  • Application Role (Any logged in user)
  • Project Role (atlassian-addons-project-access)

Close Issues
Ability to close issues. Often useful where your developers resolve issues, and a QA department closes them.

  • Application Role (Any logged in user)
  • Project Role (atlassian-addons-project-access)

Create Issues
Ability to create issues.

  • Application Role (Any logged in user)
  • Project Role (atlassian-addons-project-access)

Delete Issues
Ability to delete issues.

  • Project Role (Administrators)
  • Project Role (atlassian-addons-project-access)
  • Group (BA's)

Edit Issues
Ability to edit issues.

  • Application Role (Any logged in user)
  • Project Role (atlassian-addons-project-access)

Link Issues
Ability to link issues together and create linked issues. Only useful if issue linking is turned on.

  • Application Role (Any logged in user)
  • Project Role (atlassian-addons-project-access)

Modify Reporter
Ability to modify the reporter when creating or editing an issue.

  • Project Role (Administrators)
  • Project Role (atlassian-addons-project-access)
  • Group (BA's)

Move Issues
Ability to move issues between projects or between workflows of the same project (if applicable). Note the user can only move issues to a project he or she has the create permission for.

  • Application Role (Any logged in user)
  • Project Role (atlassian-addons-project-access)

Resolve Issues
Ability to resolve and reopen issues. This includes the ability to set a fix version.

  • Application Role (Any logged in user)
  • Project Role (atlassian-addons-project-access)

Schedule Issues
Ability to view or edit an issue's due date.

  • Application Role (Any logged in user)
  • Project Role (atlassian-addons-project-access)

Set Issue Security
Ability to set the level of security on an issue so that only people in that security level can see the issue.

  • Project Role (atlassian-addons-project-access)

Transition Issues
Ability to transition issues.

  • Application Role (Any logged in user)
  • Project Role (atlassian-addons-project-access)

Voters & Watchers Permissions

Permission

Users / Groups / Project Roles

Manage Watchers
Ability to manage the watchers of an issue.

  • Project Role (Administrators)
  • Project Role (atlassian-addons-project-access)

View Voters and Watchers
Ability to view the voters and watchers of an issue.

  • Application Role (Any logged in user)
  • Project Role (atlassian-addons-project-access)

Comments Permissions

Permission

Users / Groups / Project Roles

Add Comments
Ability to comment on issues.

  • Application Role (Any logged in user)
  • Project Role (atlassian-addons-project-access)

Delete All Comments
Ability to delete all comments made on issues.

  • Project Role (Administrators)
  • Project Role (atlassian-addons-project-access)

Delete Own Comments
Ability to delete own comments made on issues.

  • Application Role (Any logged in user)
  • Project Role (atlassian-addons-project-access)

Edit All Comments
Ability to edit all comments made on issues.

  • Project Role (Administrators)
  • Project Role (atlassian-addons-project-access)

Edit Own Comments
Ability to edit own comments made on issues.

  • Application Role (Any logged in user)
  • Project Role (atlassian-addons-project-access)

Attachments Permissions

Permission

Users / Groups / Project Roles

Create Attachments
Users with this permission may create attachments.

  • Application Role (Any logged in user)
  • Project Role (atlassian-addons-project-access)

Delete All Attachments
Users with this permission may delete all attachments.

  • Project Role (Administrators)
  • Project Role (atlassian-addons-project-access)

Delete Own Attachments
Users with this permission may delete own attachments.

  • Application Role (Any logged in user)
  • Project Role (atlassian-addons-project-access)

Time Tracking Permissions

Permission

Users / Groups / Project Roles

Delete All Worklogs
Ability to delete all worklogs made on issues.

  • Project Role (Administrators)
  • Project Role (atlassian-addons-project-access)

Delete Own Worklogs
Ability to delete own worklogs made on issues.

  • Application Role (Any logged in user)
  • Project Role (atlassian-addons-project-access)

Edit All Worklogs
Ability to edit all worklogs made on issues.

  • Project Role (Administrators)
  • Project Role (atlassian-addons-project-access)

Edit Own Worklogs
Ability to edit own worklogs made on issues.

  • Application Role (Any logged in user)
  • Project Role (atlassian-addons-project-access)

Work On Issues
Ability to log work done against an issue. Only useful if Time Tracking is turned on.

  • Application Role (Any logged in user)
  • Project Role (atlassian-addons-project-access)

Ok, that all looks correct to me.  The only thing I can think of is that the "Readers" permission scheme is not being used by the project you want to let the user(s) into.

 

Not sure if the original poster is still watching, but any Permission listed with 'Application Role (Any logged in user)' will allow the users in Group (readers) to do that action.  I got around this by making two new groups:  ReadOnly and ReadWrite and putting all my users into one or the other.  Then I changed all the Permissions that had 'Application Role (Any logged in user)' to 'Group (ReadWrite)' to filter out all the users in group ReadOnly.

Robert - your suggestion seems to make a lot sense. I will try it out and let you know if it worked.

Thanks.

@Robert Pattay: you are right. My JIRA instance lately behaved "strange", people who are put to isolated group started seeing other projects, and could create tasks in other projects (but not browse them).

I compared an old project with a new project, with a permission I never modified after creating a project.

Old:

Assign Issues
Ability to assign issues to other people.

  • Project Role (Developers)
  • Project Role (atlassian-addons-project-access)

New:

Assign Issues
Ability to assign issues to other people.

  • Application access (Any logged in user)
  • Project Role (atlassian-addons-project-access)

The difference is there. Both projects are the "Software" type, which means the default permissions have been changed by Atlassian between the old and new projects.

The Permission Helper shows this as well. (that those isolated people are able to do certain tasks because of the "Application access (Any logged in user)" permission.

Suggest an answer

Log in or Sign up to answer
Community showcase
Posted Tuesday in Jira

What modern development practices are at the heart of how your team delivers software?

Hey Community mates! Claire here from the Software Product Marketing team. We all know software development changes rapidly, and it's often tough to keep up. But from our research, we've found the h...

169 views 1 3
Join discussion

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you