Follow up to Zev Ginzburg, that will replace the Request Participants (lucky I tested on one issue first), however, in the Edit Issue for Request Participant, you can (and in many cases should) and "copy from issue" from the choices AS WELL AS the people you want to add.

This will add the EXISTING request participants, and the new ones.

And yes, it's slightly crazy that bulk edit doesn't let you do Request Participants in any way yet.

I have come up with a work around for this, not sure if it has been posted before:

In your Service Desk's settings, open the AUTOMATION tool, and create a rule based on a Schedule.

1. Select a the trigger "Scheduled"
   1. Enter in a time interval (and don't worry about a specific interval because this is a one time only job)
   2. Insert a condition based on a JQL
2. Add "New Action"
   1. Edit issue
      1. Search "Request Participant"
         1. Select a user to add
3. Publish Rule
4. Run the rule
   1. Check audit log to ensure automation ran correctly
5. If the rule ran successfully TURN THE RULE OFF.

This worked in our instance and is a much more user friendly way than potentially adding new fields, or manually adding a participant to a number of tickets.

Thanks and I hope as of today, 338 votes can constitute enough gathered interest.

• created a temporary field "TAG"

automation job

• if the field tag changes then edit issue
• edit issue "request participants" Copy from issue & name1, & name2

ran JQL query of what I wanted to update

• bulk change, Edit field "TAG"

executes the above job, appending the names added
verify job log

run JQL query of what I wanted to update + "TAG" field

• bulk change, Edit field "TAG" remove

remove the custom field from the screen schema, then finally the custom field itself

+1

+1

I was just looking for a solution to bulk-update the "Request participants" and ended up here. This feature was suggested in 2014 and is almost 8 years. @Jira, please review this suggestion and do the needful.

This feature would be really nice to have. @Jira, please take a look at this request again. Thank you very much.

This issue is open since 2014... It's a shame that 8 years after, it's not yet implemented...

Shame shame shame on you...

This is a critical feature for normal service desk operations. Would be particularly helpful for the workaround required to fix the impact of this known bug: https://jira.atlassian.com/browse/JSDCLOUD-7546

Please add the functionality Atlassian!

This would be nice to have. You can do this with the labels field when bulk editing, so why not the request participant field?

+1 this is needed both for normal operations as well as being critical for migrations into Jira

Hey Everyone,

Another simple way to Bulk Add Request Participants via JQL is leveraging the Automation For Jira Add-on. Using the scheduled trigger you can set the rule to run via a cron expression or by hitting the blue run button.

Hope this helps!

Gary

+1

Workarround

I needed to append a new user to all previous existing Jira issues.

But In order to make this process possible and since Jira doesn't support bulk request participant so far.

I created a transition and in that transition I appended the user to the request participant using Script Runner

Here is a sample of my code so you can get an idea:

 import com.atlassian.jira.component.ComponentAccessor
 import com.atlassian.jira.user.ApplicationUser
 import java.util.ArrayList
 import com.atlassian.jira.issue.ModifiedValue
 import com.atlassian.jira.issue.util.DefaultIssueChangeHolder
 import com.atlassian.jira.issue.MutableIssue
 
def customFieldManager = ComponentAccessor.getCustomFieldManager()
def userManager = ComponentAccessor.getUserUtil()
 
// request participants
def requestParticipantsField = customFieldManager.getCustomFieldObject("customfield_10000")
 
def groupManager = ComponentAccessor.getGroupManager()
ArrayList<ApplicationUser> usersToAdd = new ArrayList<ApplicationUser>()
 
//the users can be added from a group
usersToAdd.addAll(groupManager.getUsersInGroup("..."))
 
//or can be added individually using their username
usersToAdd.addAll(userManager.getUser("..."),userManager.getUser("..."))

MutableIssue myIssue = issue
myIssue.setCustomFieldValue(requestParticipantsField, usersToAdd)

Here's a Python script to bulk add Request Participants. Fill out your JQL, user list, and base url and should be set to run! Required Python3.x and requests, tested on JDC 7.13.13. YMMV, run it on Dev first, etc.

Axel - you could adapt this to meet your use case, would just have to GET the participants and DELETE whatever is returned. Hope this helps someone!

import requests
import json
import getpass
import sys

# Enter JQL for issues to add Request Participants to
search_jql = "<jql>"

# Enter usernames for RPs to add, in Python list format
addedParticipants = ["<username>", "<username>"]

# Username and password terminal input
username = input('Jira Username: ')
password = getpass.getpass()

search_url = 'https://<base-url>/rest/api/2/search'
jsd_rp_url = 'https://<base-url>/rest/servicedeskapi/request/'

# Initial search data, using a POST search for readability.
data = {"jql": search_jql,
        "fields": ["key"],
        "startAt": 0,
        "maxResults": 1000}

# Convert python dictionary to json
data = json.dumps(data)

s = requests.Session()

# Make initial request to verify creds and get total results for later
r = s.post(
        url=search_url,
        data=data,
        auth=(username, password),
        headers={'Content-Type': 'application/json'}
    )

status_code = r.status_code

# Prevents trying to run the loop with bad creds causing CAPTCHA lockout
if status_code == 401:
    sys.exit("Invalid credentials provided, please check username/password")

total = r.json()["total"]
startValue = 0
results = []

# Get issue keys from search, write to list.
while startValue < total:

	data = {"jql": search_jql,
        "fields": ["key"],
        "startAt": startValue,
        "maxResults": 1000}

	data = json.dumps(data)

	r = s.post(
	        url=search_url,
	        data=data,
	        headers={'Content-Type': 'application/json'}
	    )

	for issues in r.json().get("issues"):
		results.append(issues["key"])

	startValue += 1000

for issue in results:
	key = issue

	data = {"usernames": addedParticipants}
	data = json.dumps(data)

	r = s.post(
	        url=jsd_rp_url + key + "/participant",
	        data=data,
	        headers={'Content-Type': 'application/json'}
	    ) 

+1

I understand that this feature would be very complex to implement in a general case. It would have to supply for

• adding a participant
• removing a participant
• maybe even replacing a participant.

My usecase for bulk-edit participants is much simpler:

• remove any participants

Background:

We used the default service desk screen schema for a few years. It allows agents to enter participants for sub-tasks, which is quite missleading, as customers can never access sub-tasks. They are internal by design.

We now corrected the screen schema and removed fields participants, organizations and approvers for sub-tasks.  Now we would like to clear the field participants for those 300 sub-tasks where it is not empty.

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 to push the topic. 

I have department heads change pretty frequently, and need the ability to add them to see older tickets/open tickets without manually going and changing one by one. 

+1 to push the topic and make it happen. Thanks

A new department starts opening up their internal requests to our service desk users. Instead of beeing able to add in all supervisiors, stand-ins, temporary replacements, heads of departments etc. via a quick bulk edit, this has to be done manually for every ticket now. Not that great.

A Service Desk user changed their name and consequently their email address and login.  I need to be able to bulk edit the request participants to update from the old to the new.

I have created organisation and added team members which I want to add as participant to that particular Jira item.

Now, as suggested in above comment from Ted, I have added this organisation to multiple JIRA's using bulk operation.

Will this behave same as adding individual participants to  Jira item? I want to notify each member of organisation about any change to that particular JIRA. 

I'm sure my comment will be buried, but I discovered a workaround that hopefully will help anyone that stumbles across this issue. User QTAC commented about this feature above as well. Rather than adding users in bulk to request participants, you can add organizations in bulk, and add one or more users to the organization.

Any update on this Atlassian?

almost 4 years!

unbelievable. Need that too.

We need as well this feature. Please Atlassian, give a feedback about the progress.

+100500

Need strongly!

Hey Atalassian,
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?