Uploaded image for project: 'Jira Data Center'
  1. Jira Data Center
  2. JRASERVER-5865

Provide ability for permission schemes to be configured per issue type

XMLWordPrintable

    • 32
    • Hide
      Atlassian Update – 1 October 2018

      Hi everyone,

      Thank you for sharing your comments on permission schemes per issue type. This suggestion has been resolved as Won’t Fix in 2011, but recently, while updating the workflow for all suggestions on jira.atlassian.com we have changed the status from Closed to Resolved. This technical change triggered a few questions from you, so we’ve decided to post an update for clarity.

      We have reviewed this suggestion again and how it would fit alongside our strategy and other customer priorities. We will not be re-opening the suggestion because we are not planning to invest in adding permissions per issue type in Jira. While we absolutely understand the logic behind this request, we strongly believe that we should focus on making Jira simpler and easier to use rather then introduce additional complexity. We stand by the decision posted by Roy Krishna in 2011 in this comment.

      Meanwhile, in some of the contexts this knowledge base article can be useful How to set the Security Level of an issue based on group membership.

      Kind regards
      Katarzyna Derenda
      Product manager, Jira Server

       

      Show
      Atlassian Update – 1 October 2018 Hi everyone, Thank you for sharing your comments on permission schemes per issue type. This suggestion has been resolved as Won’t Fix in 2011, but recently, while updating the workflow for all suggestions on jira.atlassian.com we have changed the status from Closed to Resolved. This technical change triggered a few questions from you, so we’ve decided to post an update for clarity. We have reviewed this suggestion again and how it would fit alongside our strategy and other customer priorities. We will not be re-opening the suggestion because we are not planning to invest in adding permissions per issue type in Jira. While we absolutely understand the logic behind this request, we strongly believe that we should focus on making Jira simpler and easier to use rather then introduce additional complexity. We stand by the decision posted by Roy Krishna in 2011 in this comment. Meanwhile, in some of the contexts this knowledge base article can be useful  How to set the Security Level of an issue based on group membership . Kind regards Katarzyna Derenda Product manager, Jira Server  
    • 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.

      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).

        1. D3904554-8F1C-8F48-9B44-FF092AD4E845(2)
          7 kB
        2. D3904554-8F1C-8F48-9B44-FF092AD4E845(2)
          7 kB
        3. D3904554-8F1C-8F48-9B44-FF092AD4E845(2)
          7 kB

            [JRASERVER-5865] Provide ability for permission schemes to be configured per issue type

            Zul NS [Atlassian] added a comment -

            e9422b0ccef0, apologise for that. The linked KB article should be viewable now. Have a great week!

            Zul NS [Atlassian] added a comment - e9422b0ccef0 , apologise for that. The linked KB article should be viewable now. Have a great week!

            Jo Favoreel added a comment -

            https://confluence.atlassian.com/jirakb/how-to-set-the-security-level-of-an-issue-based-on-group-membership-726565612.html seems to lead to /dev/null?

            Jo Favoreel added a comment - https://confluence.atlassian.com/jirakb/how-to-set-the-security-level-of-an-issue-based-on-group-membership-726565612.html seems to lead to /dev/null?

            Piotr Janik added a comment - - edited

            There's no analogy with workflows, screens and fields in the current design. If they can be customized per issue type, why not permissions?

            Piotr Janik added a comment - - edited There's no analogy with workflows, screens and fields in the current design. If they can be customized per issue type, why not permissions?

            Michael Bruns added a comment -

            "While we absolutely understand the logic behind this request, we strongly believe that we should focus on making Jira simpler and easier to use rather then introduce additional complexity. "
            Not necessarily from the perspective of the end user.

            Michael Bruns added a comment - "While we absolutely understand the logic behind this request, we strongly believe that we should focus on making Jira simpler and easier to use rather then introduce additional complexity. " Not necessarily from the perspective of the end user.

            Daniel Valenzuela added a comment -

            +1

            Daniel Valenzuela added a comment - +1

            Ioulia Kalpakoula added a comment -

            +1 this feature would make our work with Jira so much easier. We are trying to figure out a workaround right now but haven´t been successful so far. 

            Ioulia Kalpakoula added a comment - +1 this feature would make our work with Jira so much easier. We are trying to figure out a workaround right now but haven´t been successful so far. 

            altamirasoftworks added a comment -

            +1

            altamirasoftworks added a comment - +1

            3layer Gestão Compartilhada added a comment -

            +1

            I believe this feature would be very interesting. We have several separate issue types and today to restrict the creation we have to use a user/group validator, but even so any user can fill in the fields, etc., until they receive the error alert.

            It would be enough to apply where there is a user create validator, showing only those types of items for each user.

            3layer Gestão Compartilhada added a comment - +1 I believe this feature would be very interesting. We have several separate issue types and today to restrict the creation we have to use a user/group validator, but even so any user can fill in the fields, etc., until they receive the error alert. It would be enough to apply where there is a user create validator, showing only those types of items for each user.

            Vladislav Dorozhko added a comment -

            +1

            It would be much more convenient for teams to have the access to the permitted issue types only, rather picking target issue type from the 15 items list

            Vladislav Dorozhko added a comment - +1 It would be much more convenient for teams to have the access to the permitted issue types only, rather picking target issue type from the 15 items list

            Philippe Collin added a comment -

            Is there no creative workaround for this? This is a huge ask for anyone that is managing a company with multiple teams. For instance a QA team should only be allowed to enter "QA Test Case" or "QA Bug" and client testing, during UAT, should only be able to add "UAT Bug" and Technical Leads should only be abl to add "Task", "Story", or "Sub Task". 

            This is pretty common. I agree this absolutely would make Jira much easier.

            Philippe Collin added a comment - Is there no creative workaround for this? This is a huge ask for anyone that is managing a company with multiple teams. For instance a QA team should only be allowed to enter "QA Test Case" or "QA Bug" and client testing, during UAT, should only be able to add "UAT Bug" and Technical Leads should only be abl to add "Task", "Story", or "Sub Task".  This is pretty common. I agree this absolutely would make Jira much easier.

              Unassigned Unassigned
              ajskdlf ajskdlf
              Votes:
              327 Vote for this issue
              Watchers:
              413 Start watching this issue

                Created:
                Updated:
                Resolved: