NOTE: This suggestion is for JIRA Cloud. Using JIRA Server? See the corresponding suggestion.

Hi everyone,

Thanks for your comments and feedback, we really appreciate your engagement. We've made the decision to close this issue because we want to send a clear message that this is not something JIRA is going to support.

First, a few thoughts on this issue in particular.

• JIRA permission schemes are already very granular and complex. There are several dozen individual permissions that an administrator needs to understand. If these different sets of permissions were mapped at the issue type level, this would multiply the complexity.
• In our research, we already see major confusion between schemes that map configuration to issue types versus schemes that map configuration to projects.
  • Issue type schemes, permissions, notifications, and issue security are all associated directly to a project
  • Workflow schemes, field configuration schemes, and issue type screen schemes map configuration to issue types
• If you were to change the behavior of permission schemes so that they mapped a permission configuration to issue types, you would need to introduce a second layer – a permission configuration per issue type, and then a permission scheme to associate that set of configurations to a project.
• This is the exact opposite of the direction we want to go with JIRA. We are investing heavily in reducing complexity in JIRA administration to make it more accessible to more users.

This does not mean that the needs of JIRA admins are not important. Improving performance and simplifying project configuration are the top two priorities for the JIRA development team for the foreseeable future. However, when looking holistically at how we can improve the project configuration experience in JIRA, this request doesn't fit in to our vision.

A note on requests on jira.atlassian.com:

• We take the feedback and votes on feature requests on jira.atlassian.com seriously. Certainly the fact that there's 144 votes for this request and it's already been closed before doesn't go unnoticed.
• When we make the decision to close an issue, our goal is to make a clear statement about which features we realistically expect to support in JIRA and which features we don't expect to implement, at least not in the way they have been described in the feature request. While it might be painful or frustrating in the short term, we strongly committed to communicating our intentions as openly as possible. Everyone is better off in the long run.
• We have a detailed explanation of how we use jira.atlassian.com and how we develop our roadmap here.

We're currently in the midst of updating almost every feature request in the JRA project with a significant number of votes. Our hope is that the conclusion you draw is not that Atlassian doesn't care, but that we are trying to focus on the improvements that will the largest benefit for the most customers, and unfortunately this means that we simply cannot work on the vast majority of the hundreds of feature requests at once.

Feel free to contact me at any time if you have feedback or questions. My email address is dmeyer@atlassian.com.

Thanks,
Dave Meyer
Product Manager, JIRA