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

[Winfred]

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:

• Blog: Share JIRA with external partners
  https://www.atlassian.com/blog/archives/share-jira-external-partners
• project permission scheme:
  https://confluence.atlassian.com/adminjiraserver073/managing-project-permissions-861253293.html
• issue level security:
  https://confluence.atlassian.com/adminjiraserver071/configuring-issue-level-security-802592414.html

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.

[Nic Brough -Adaptavist-]

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.