Uploaded image for project: 'Jira Platform Cloud'
  1. Jira Platform Cloud
  2. JRACLOUD-2414

add "project group" feature to ease permissions management

XMLWordPrintable

    • Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our new feature policy.

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

      all our projects have the same set of permissions, however, we have to implement a distinct permission scheme for each project, because we have "project groups" where only users assigned to that project can edit/schedule/assign/assignable/resolve issues.

      this means creating a separate permission scheme for each project, copying another, and removing one set of groups and adding another.

      if 'project group' were an option on the Add New Permission page, this would greatly simplify our administration. one way to make this work would be that if project-group were seleted, anyone in a group with the SAME NAME as the project would be given that permission.

      alternately, the database structure could be modified to allow assigning one (add fk) or more than one (new table), but this would probably be a lot more work.

            [JRACLOUD-2414] add "project group" feature to ease permissions management

            Rizwan Akbar added a comment - - edited

            Dear Jira Team,

            I also about to report a suggestion related to it. There MUST be a concept of Teams with designation and expertise in Jira so that we can better management the users and teams. Also, there should be a permission type, "Team Members". If someone selected this option in Permission Schemes, anyone in the team can access that functionality.

            We have 9 projects and if we do not want the team to see each other project, we have to create 9 Permission Schemes. If you implement Team Members and a permission type then one can manage multiple projects with one Permission Scheme.

            Best Regards,
            Rizwan Akbar

            Rizwan Akbar added a comment - - edited Dear Jira Team, I also about to report a suggestion related to it. There MUST be a concept of Teams with designation and expertise in Jira so that we can better management the users and teams. Also, there should be a permission type, "Team Members". If someone selected this option in Permission Schemes, anyone in the team can access that functionality. We have 9 projects and if we do not want the team to see each other project, we have to create 9 Permission Schemes. If you implement Team Members and a permission type then one can manage multiple projects with one Permission Scheme. Best Regards, Rizwan Akbar

            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

            Evan Leonard added a comment -

            More information regarding my last comment: I noticed that "multiple project support for GH" is on the way. This is good, however, if this is going to be the recommended mode for coordinating teams there are remaining issues to be considered. For example, if there is a project per team, where do you submit bugs that are found in released versions? Do you have to make another project just for a bug database? If so, then how do you pull bugs into the teams' projects without moving them (making the bug database project less useful) and without duplicating them (adding extra steps of work)?

            Evan Leonard added a comment - More information regarding my last comment: I noticed that "multiple project support for GH" is on the way. This is good, however, if this is going to be the recommended mode for coordinating teams there are remaining issues to be considered. For example, if there is a project per team, where do you submit bugs that are found in released versions? Do you have to make another project just for a bug database? If so, then how do you pull bugs into the teams' projects without moving them (making the bug database project less useful) and without duplicating them (adding extra steps of work)?

            Evan Leonard added a comment -

            This concept will be useful elsewhere in the product. For instance, right now it is awkward to map a single backlog in GH to sprints running in different teams (see: http://jaibeermalik.wordpress.com/2010/07/22/using-greenhopper-to-manage-multiple-teams-in-agile/). It would be better if teams were a top-level concept that could be associated with jira projects and the sprints within them.

            Evan Leonard added a comment - This concept will be useful elsewhere in the product. For instance, right now it is awkward to map a single backlog in GH to sprints running in different teams (see: http://jaibeermalik.wordpress.com/2010/07/22/using-greenhopper-to-manage-multiple-teams-in-agile/ ). It would be better if teams were a top-level concept that could be associated with jira projects and the sprints within them.

              Unassigned Unassigned
              d32fc554e6cd Tim Dawson
              Votes:
              9 Vote for this issue
              Watchers:
              4 Start watching this issue

                Created:
                Updated:
                Resolved: