Ran into this problem again last week - there are now over 500 votes for this function across the cloud and server tickets. rcrossman@atlassian.com  is there any chance of an update on this please? 

We ran into this limitation in Data Center recently, so when I went out to the Cloud version I was disappointed to see this problem hadn't yet been addressed. It looks like there are a variety of fields like this one that can't be edited in bulk. If it's possible to achieve via the API, it should be possible to implement within the UI.

If someone from Atlassian could comment regarding the issues implementing this and/or a timeline, that would be appreciated since we're coming up on almost 10 years now with over 200 votes.

+1
yes, ASAP please!

Totally agree - this is long overdue and would be very welcome. 

Since 2014?
Come on team, how many more years this ticket going to be at here?

I need this as soon as practical. I have 120+ different organisations, each with many different requestors. They often ask me to add new people to all ticket history which I have no sensible way to do.

This would be a fantastic update and a definite help for us. (and apparently several others)  

This seems like a fairly simple update in the bulk edit feature...are there any plans to make this update? It would really help our processes.

+1

@Kasia - yep pretty much, although some of us (me) have just given up. I personally am no longer an active user of any Atlassian product due to basic issues like this languishing for years.

Perhaps though, one day our grandchildren or their grandchildren may see this feature implemented.

So you all have been sitting on this since 14/Dec/2014??? Are you kidding me? 9 YEARS today and no way to add that simple change? 

+1

+1

+1

Hi, I'd find this useful also! Thank you

This feature is essential and would be very helpful for me and my teams, especially given this bug which requires changes to the Request Participant field as a workaround is still unresolved: 

https://jira.atlassian.com/browse/JSDCLOUD-7546

Please prioritize this feature as well as a fix for the bug!

+1

+1

+1 please. Essential feature.

Thanks all for your feedback here and to Rodolfo for flagging this issue. We recognise this is needed and will be looking into it in future. We won't, however, be able to focus on this in the short- to medium-term and apologise for any inconvenience that causes.

Best regards,

Jehan Gonsalkorale

Product manager, Jira Service Management

+1

This ticket is open for 6 years already, can we please get some feedback as what is happening?

The fact that customers cannot update their email addresses makes this feature required. We have to create new accounts for all of our customers that just changed email addresses, and there is no way to add their new account as a request participant on their currently active tickets. What a total mess.

+1 please.

Very useful for when someone leaves the organisation, and you want their replacement to see the same open tasks.

We currently have an unlimited license and find it difficult to act as an 'enterprise' customer when this functionality is missing.

Just to add my vote here, and some clarification. There should be several "bulk" operations for request participants.

1) Remove user A from request participants.

2) Add user A to request participants

3) Set list of request participants to a particular list

Hey,

I just ran into this issues as well, any updates?

Cheers

Hey Atlassian,
Is there any progress on this?

The OP created this in 2014 - last official response on this original thread was in May 2015, nothing since.

There are many limitations that could make sense when the product was launched, but no longer do when investing over $20k a year for a Service Desk that is behind its competition (for usability, there is no denying that Jira Core and Software are industry standards and very powerful).

+1 for reasons already stated in the other comments

This would be very useful. Our testers generate 100's of ticket during a test session and at the moment we have to go through one at a time to grant the customer access to see can comment on the tickets by adding them in as a participant.

We need this too

Customers manage their tickets as a group, and when they get new staff they want them to be able to see all open and past tickets. I have a customer trying to add new employees to ~500 tickets. Even adding them to just the open 40+ tickets is tedious.

+1

We run several Cloud Service Desks, and when a customer goes on leave or adds a member of their team, we have to manually add new participants in hundreds of current Issues/tickets.
It would be a time saver to be able to add participants via the bulk actions.

+1

+1

This is needed so when we implement JIRA Service Desk we can transition customers to the portal and allow them to see other requests from the same organisation (as JSD-270) would like, but as that is not in, we need to bulk edit, as individually changing hundreds of issues for request participants isn't ideal.

We have a couple scenarios and this is particularly helpful since JSD-270 is unresolved.

• A department head or administrative assistant wishes to review current or past issues submitted by their department.

• Due to staff turn-over a new employee wants to view current and previous requests submitted by an employee inheriting the same position.

Hi guys,
Could you help me understand when you'd want to bulk edit 'request participants' on multiple issues? – Cheers, Lingbo

This is very much needed functionality for us and I don't quite understand why the request participants field isn't treated like any other custom field.

Also has anyone had any success with a workaround?