• 361
    • 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 Service Management Cloud. Using Jira Service Management Server? See the corresponding suggestion.

      We have a Jira group that needs to have access to requests. It would be great if we can add a group to the "Request participants" field, instead of having to add each user one by one.

      Workaround

      The doc below contains a workaround for this Feature Request:
      How to add group members as request participants

      Many customers previously requested a way to group customers so it's easier for them to view and share each others' requests. The Jira Service Desk (now Jira Service Management) team released 'organizations' in 2017 to address this use case. 

      Organizations are groups of customers that you can add to multiple projects. Customers can be members of multiple organizations, and can:

      • raise requests in all projects that use the organization.  
      • view and search the organization's requests from the My Requests page in the portal.
      • receive notifications about the organization's requests.
      • share requests with the organization. 

      Learn more about organizations by referring to our documentation here.

            [JSDCLOUD-1268] Support adding a Jira group to the "Request participants" field

            Happy New Year, everyone! May it be filled with joy, success, and - who knows - maybe even some miracles. Like Atlassian resolving to fix this bug. We can dream, right?

            Tobias Bosshard added a comment - Happy New Year, everyone! May it be filled with joy, success, and - who knows - maybe even some miracles. Like Atlassian resolving to fix this bug. We can dream, right?

            Corne Cloete added a comment - - edited

            Atlassian too busy on working on new ways to charge more for the same service....instead of actually implementing basic features/requests.

            Corne Cloete added a comment - - edited Atlassian too busy on working on new ways to charge more for the same service....instead of actually implementing basic features/requests.

            L M added a comment - - edited

            I'm once again absolutely flabbergasted that this feature is not only not implemented since release, but also STILL not implemented AFTER 10 YEARS and many requests. Very disappointing for such an expensive product, I will probably never consider any Atlassian products ever again.

            L M added a comment - - edited I'm once again absolutely flabbergasted that this feature is not only not implemented since release, but also STILL not implemented AFTER 10 YEARS and many requests . Very disappointing for such an expensive product, I will probably never consider any Atlassian products ever again.

            +1

            Alejandro Scuncia (Inactive) added a comment - https://getsupport.atlassian.com/browse/PCS-144880

            I think that this requires a new field type that allows individuals and groups to be added to it which does not exist out of the box currently. There is only the single/multipe User Picker or Group Pickers.

            Alternatively, (but faster) you can just have an additional group picker field for Participant Groups, but this could be confusing for users? As a bad workaround agents could add a group to Participant Groups which then populates the request particpants

            Then the functions that allow a request participant to collaborate need to be changed so that it checks whether the current user is a member of the added group(s).

            In addition to this I think similar functionality of Request Particpants should be available for agents for cross project collaboration. Currently the only way to do this is provide browse permission to agents in another project, however for a HR project or Legal project you wouldn't want to provide browse access to ALL the tickets in the project, only the tickets that you want to share with the other project team. This actually aligns with the Atlassian vision of having multiple back office 'Jira Service Management - Service Centres' for front / back office functions that can collaborate with eachother effectively accross projects.

            It's disappointing that something this useful has been asked for 8 years ago, marked as fixed and is still gathering interest. It doesn't fill me with any hope that this will actually get implemented.

            David Meredith added a comment - I think that this requires a new field type that allows individuals and groups to be added to it which does not exist out of the box currently. There is only the single/multipe User Picker or Group Pickers. Alternatively, (but faster) you can just have an additional group picker field for Participant Groups , but this could be confusing for users? As a bad workaround agents could add a group to Participant Groups which then populates the request particpants Then the functions that allow a request participant to collaborate need to be changed so that it checks whether the current user is a member of the added group(s). In addition to this I think similar functionality of Request Particpants should be available for agents for cross project collaboration. Currently the only way to do this is provide browse permission to agents in another project, however for a HR project or Legal project you wouldn't want to provide browse access to ALL the tickets in the project, only the tickets that you want to share with the other project team. This actually aligns with the Atlassian vision of having multiple back office 'Jira Service Management - Service Centres' for front / back office functions that can collaborate with eachother effectively accross projects. It's disappointing that something this useful has been asked for 8 years ago, marked as fixed and is still gathering interest. It doesn't fill me with any hope that this will actually get implemented.

            With regard to the suggestion to using "organisations" as a workaround, that isn't going to be viable for the way our users interact with Service Desk.

            A lot of our users still like raising tickets via email. It allows them to CC a whole bunch of people who then get added as Request Participants.

            The problem we see is when one of the CC'd entities is a group. If that group does not yet exist in Service Desk as a customer, Service Desk sends out an email to that group in order to confirm it is a valid email address. When the first person in the group clicks on the link, that then associates THEIR email address with the group's name in Service Desk. This causes all sorts of confusion.

            The frustrating thing is that Service Desk already knows about our groups because users and groups are synced. The current behaviour and handling around groups is broken.

            Philip Colmer added a comment - With regard to the suggestion to using "organisations" as a workaround, that isn't going to be viable for the way our users interact with Service Desk. A lot of our users still like raising tickets via email. It allows them to CC a whole bunch of people who then get added as Request Participants. The problem we see is when one of the CC'd entities is a group. If that group does not yet exist in Service Desk as a customer, Service Desk sends out an email to that group in order to confirm it is a valid email address. When the first person in the group clicks on the link, that then associates THEIR email address with the group's name in Service Desk. This causes all sorts of confusion. The frustrating thing is that Service Desk already knows about our groups because users and groups are synced. The current behaviour and handling around groups is broken.

            +1 please reopen.

            ian.johnsen added a comment - +1 please reopen.

            Also hoping that adding a comment here will get this feature focus by Atlassian.   It's been over 5 years since this has been closed/fixed but the feature does not exist on JSD Cloud.  

            Jason Duhamel added a comment - Also hoping that adding a comment here will get this feature focus by Atlassian.   It's been over 5 years since this has been closed/fixed but the feature does not exist on JSD Cloud.  

            +1 How could it be marked as FIXED - even 4 years after the last comment?

            Do someone get info about "this comment"? LOL

            Andreas Lärkfeldt added a comment - +1 How could it be marked as FIXED - even 4 years after the last comment? Do someone get info about "this comment"? LOL

              Unassigned Unassigned
              6e107d394ed3 Rodolfo
              Votes:
              240 Vote for this issue
              Watchers:
              135 Start watching this issue

                Created:
                Updated: