Uploaded image for project: 'Jira Server and Data Center'
  1. Jira Server and Data Center
  2. JRASERVER-42116

Reopen 5865 : Allow permission schemes to be configured per issue type

    XMLWordPrintable

Details

    • 32
    • We collect Jira feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

    Description

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

      Atlassian Update 23 December 2015

      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

      Reopen JRA-5865 created 10 years ago. I understand the reason why you didn't implement this but there's a LOT or people and company wanting this feature. There's still a lot of activity on the issue comment.

      Please reconsider implementing this feature.

      Now, when a group has the permission to create an issue, it could create EVERY types of issues available. It's a complement to project specific issues types. (http://jira.atlassian.com/browse/JRA-1602)

      For example, If we have external client (like me right now ) I would be interrested to limit his issue creation right to only bugs, features, external client requests (custom type).

      Attachments

        Issue Links

          Activity

            People

              Unassigned Unassigned
              c82f87d62c68 François-Xavier Choinière
              Votes:
              145 Vote for this issue
              Watchers:
              98 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: