example of permission scheme to allow customer access to certain issues and types

Was going through the community posts and the documentation, but could not find the answer for what I am trying to achieve. I am relatively new to Jira.

My setup: Jira Core Server (7.3.6), we have a development team, a project role Customer (and user group project-customer). We have a single project, with issue types for Bugs and RFE's.

Would like to achieve:

  • default: the default permission scheme's. Exceptions for the project role Customer. They can not do anything except a few things.
  • they can read/create all tickets of issue type RFE
  • they can view/comment on their own tickets.
  • they can not see the other issues / types
  • a developer could decide to add a Customer user to a specific Bugs issue.

Was looking at:

But I have not yet found the full set of instructions / options that I'm looking for.

  • I have created a custom permission scheme
  • Do I have to delete all default permissions ("application access - any logged in user")?
  • Do I have to manually replace that each of these default permission with Project Role - "Internal team"?
  • I would rather only add the exception: Role "Customer" creates limits for those users.
  • How do I achieve issue type restrictions? Regular users can read/create all issue types, Customer users can only create RFE's/Bugs, they can read all RFE's and their own Bugs.

1 answer

Comments Closed
0 votes

The project permission scheme doc is the most useful one here, although it is quite long and not a tutorial. 

You have got the right general idea on this, so I'll go over your points in order.

You've created a new permission scheme - excellent

Yes you would have to delete the defaults as they let everyone in

Yes, you should replace that with the access you want to let people have (role - internal team sounds right)

Your customers will need "create" permissions

And this is where it goes wrong.  There are no issue type restrictions.  If a user has "create" in a project, they can create issues, of any type.  There is no native way to stop them creating any type.  Your options are to create "impossible validation" which is ugly because it loses the user's input, or to find something that can modify the front end (such as Script Runner's Behaviours)

Last, you've mentioned "can only see their own stuff".  There are two ways to do this.  The one a lot of people use is security levels, but you will need to find a post-function that can set the security level on the "create issue" transition.

The better way to do it is with "reporter browse" permission though.  When you put "Browse project: reporter" in a permission scheme, it does not mean "only the reporter can see this", it means "anyone who could be the reporter can see this", so it opens it up to most of the project.  The special "reporter browse" permission does mean "only reporter", but you have to enable it by setting a flag on the file system and restarting JIRA, which you can only do on Server or Data Centre.

So, I think you're close already, but your last two requirements aren't simple permissions and need more thought.

 

 

Community showcase
Published Monday in Jira Ops

Jira Ops Early Access Program Update #1: Announcing our next feature and a new integration

Thanks for signing up for Jira Ops! I’m Matt Ryall, leader for the Jira Ops product team at Atlassian. Since this is a brand new product, we’ll be delivering improvements quickly and sharing updates...

417 views 0 8
Read article

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