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

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

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.

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.

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

Atlassian, this still has neither been fixed nor implemented, yet it was marked as "Fixed" and has been closed since October of 2016. While I do enjoy trawling through volumes and volumes of abandonware and straight-up vaporware, this approach is really getting old. I'll admit that at times it's entertaining to be reminded how high "making our products usable for our paying customers" is on your list of priorities, but for the most part all you're doing is alienating your remaining customer base.

But hey, at least we have mandatory SSO, right?

Resolution is set to fixed, but Fix Version isn't set. From which Service Desk version is it working?

Hi,

This feature would be really, really useful.

We currently have a group of users overseas, whose systems are currently down.
Work is being carried out on this issue and we would like to have a simple way to keep these users updated.
We would have like to been able include this list of users as a group into the Request Participants field of the raised ticket.
Instead, we had to identify the key contacts and add them individually.
Taking this approach wasted a lot of time when there were more important aspects (systems down) to worry about.

Thanks for your support.

bernard gorman
Samsung
Cambridge, UK

Agreed! I just submitted a ticket requesting such a feature. Please help make this possible. It would make the system a bit better.

We would also very much love to see this feature added!

Hi all, yes @Timothy Harris.
This would be a great feature I'd appreciate in our workflow when I need to keep in loop supervisors in specific tickets.
Atlassian please consider it.
Thanks

This feature would really improve our Support & Request workflow!

Anybody out there? I know this is not Atlassian answers, but I am a bit desperate here. Was playing around with script runner. I can see the custom field values. Now what type do I need to create to add to the custom field? seems to be this type: ParticipantsCFType, but this is not accessible is it?

Is it possible to add request participants programmatically? I was thinking about using a script runner post condition groovy script to add request participants based on groups.

But I would need a Java API for this...

This would be exceptionally handy - we have groups of considerable amounts of people and this would be a huge savior.

having the ability to enable groups in the Request Participants would be great but you should somehow have the ability to control which groups are listed.
Another option is just allow a Group selection custom field to be added to the Portals page and then allow them to be added to the Notifications scheme.

We would very much like this feature!