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

permission scheme administration improvements

XMLWordPrintable

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

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

      Concerning permission scheme administration, we've got a proposal to relieve some stress of a jira admin

      Currently it's possible to copy an existing scheme. However, the new scheme is called "copy of ..." and contains the exact same groups as its ancestor (the original). Usually we want to copy a scheme but we want the same "kind" of groups in the new scheme but they have different names. An example.

      Suppose we've got a project called XXXX with its associated permission scheme XXXX.

      Permission scheme XXXX contains the following groups:

      • XXXX-users
      • XXXX-developers
      • XXXX-administrators

      We create a new project YYYY and want permission scheme YYYY. For this group YYYY we want the same groups as in scheme XXXX with different but analogous names.

      Scheme YYYY

      • YYYY-users
      • YYYY-developers
      • YYYY-administrators

      So, actually, these were a lot of words to ask only for a possibility to do a "find/replace" when copying a permission scheme. Automatically creating the new groups of the new scheme if they don't exist yet is yet another small thing to make the life of an admin a little less painful

            [JRASERVER-2018] permission scheme administration improvements

            Kerrod Williams (Inactive) added a comment -

            Thanks for taking the time to raise this issue.

            Due to the large volume of JIRA feature suggestions, we have to prioritise our development efforts. In part, that means concentrating on those issues that resonate the most with our users.

            I am writing this note to advise you, that we have decided to close your Suggestion as it has not gained traction on jira.atlassian.com. We believe being upfront and direct with you will assist you in your decision making rather than believing Atlassian will eventually address this issue.

            Thank you again for your suggestion and if you have any concerns or question, please don’t hesitate to email me.

            Kind Regards,
            Kerrod Williams
            JIRA Product Management
            kerrod.williams at atlassian dot com

            Kerrod Williams (Inactive) added a comment - Thanks for taking the time to raise this issue. Due to the large volume of JIRA feature suggestions, we have to prioritise our development efforts . In part, that means concentrating on those issues that resonate the most with our users. I am writing this note to advise you, that we have decided to close your Suggestion as it has not gained traction on jira.atlassian.com. We believe being upfront and direct with you will assist you in your decision making rather than believing Atlassian will eventually address this issue. Thank you again for your suggestion and if you have any concerns or question, please don’t hesitate to email me. Kind Regards, Kerrod Williams JIRA Product Management kerrod.williams at atlassian dot com

            Kristof Van Cleemput added a comment -

            Thx.
            Voted for them.

            Kristof Van Cleemput added a comment - Thx. Voted for them.

            Jeff Turner added a comment -

            I have moved the first part out into a separate issue (JRA-8895).

            The remaining suggestion is a good one, and would be addressed by allowing permission schemes to be defined in terms of roles ('the project users group'), rather than actual groups. This way, a single generically defined scheme can apply to multiple projects.

            Role-based permissions is being tracked in JRA-2816, so please subscribe/vote for that issue.

            Cheers,
            Jeff

            Jeff Turner added a comment - I have moved the first part out into a separate issue ( JRA-8895 ). The remaining suggestion is a good one, and would be addressed by allowing permission schemes to be defined in terms of roles ('the project users group'), rather than actual groups. This way, a single generically defined scheme can apply to multiple projects. Role-based permissions is being tracked in JRA-2816 , so please subscribe/vote for that issue. Cheers, Jeff

            Owen Fellows added a comment -

            The first part of this issue is duplicated by the linked issue.

            The second part of the Issue can be done using a Jelly script to create a new project permissions schemes etc. This a powerful way to perform common macros. If you need more assistance with Jelly please contact support@atlassian.com

            Owen Fellows added a comment - The first part of this issue is duplicated by the linked issue. The second part of the Issue can be done using a Jelly script to create a new project permissions schemes etc. This a powerful way to perform common macros. If you need more assistance with Jelly please contact support@atlassian.com

              Unassigned Unassigned
              a8c2c1de0928 Kristof Van Cleemput
              Votes:
              10 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated:
                Resolved: