nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Remove "Request Participants" using Automation rule?

Vasumathi Jayakumar_hf37pn

I am using Jira Service Desk cloud version. The issues created on service desk via email takes the cc into Request participant. I would like to automaticalyy remove some specific participants when the issue is created.

Thanks in advance for the time !

Accepted answers

All comments

Andy Heinzer

At the moment within JIRA, there is not a way to add requested participants via automation. There is a feature request for this over in JSDSERVER-3628 As such I believe the same is true for removing users via this method as well.

However there is a KB that you could use to add users, provided you use the scriptrunner plugin with JIRA and a custom script. Details on this are in How to Automatically Add Request Participants when Creating an Issue - JIRA KB

It might be possible to use the same steps, but then modify the existing script so that it could be used to either clear that field or remove a specific user depending on your needs.

smilek1234

Any solution? I want to do the same thing, remove Request Participants added from cc in e-mail. By JSON "add" or "set", its the same. It just add chosen user to RP. Can't clear that field. Any advice?

Thank you!

James_Mclellan

import com.atlassian.jira.event.issue.IssueEvent
import com.atlassian.jira.event.issue.DelegatingJiraIssueEvent
import com.atlassian.jira.user.ApplicationUser
import com.atlassian.jira.component.ComponentAccessor
import com.atlassian.jira.issue.CustomFieldManager
import com.atlassian.jira.issue.fields.CustomField
import com.atlassian.jira.issue.MutableIssue
import com.atlassian.jira.issue.ModifiedValue
import com.atlassian.jira.issue.fields.layout.field.FieldLayoutItem
import com.atlassian.jira.issue.fields.layout.field.FieldLayoutManager
import com.atlassian.jira.issue.util.DefaultIssueChangeHolder
import com.atlassian.jira.ComponentManager

def issue = event.getIssue()

// Get the list of participants
def customFieldManager = ComponentAccessor.getCustomFieldManager()
def fieldLayoutManager = ComponentAccessor.getFieldLayoutManager()
def requestField = customFieldManager.getCustomFieldObjects(issue).find {((CustomField)it).name == "Request participants"}
def participants = issue.getCustomFieldValue(requestField)
def filteredParticipants = new ArrayList<ApplicationUser>()
if (participants != null) {
 for (ApplicationUser participant in (ArrayList<ApplicationUser>)participants) {
   if ( participant.getEmailAddress().toLowerCase() != "ADDRESS_I_WANT_TO_FILTER" )
   {
     filteredParticipants.add(participant) 
   }
 }
} 

MutableIssue editableIssue = (MutableIssue)issue
editableIssue.setCustomFieldValue(requestField, filteredParticipants)
Map<String, ModifiedValue> modifiedFields = editableIssue.getModifiedFields();
FieldLayoutItem fieldLayoutItem = fieldLayoutManager.getFieldLayout(editableIssue).getFieldLayoutItem(requestField);
DefaultIssueChangeHolder issueChangeHolder = new DefaultIssueChangeHolder();
final ModifiedValue modifiedValue = (ModifiedValue) modifiedFields.get(requestField.getId());
requestField.updateValue(fieldLayoutItem, issue, modifiedValue, issueChangeHolder);

Christoffer

This causes errors for me, i have no experience with scripts, any ideas?

2017-11-13 15:18:07,526 ERROR [workflow.ScriptWorkflowFunction]: *************************************************************************************
2017-11-13 15:18:07,526 ERROR [workflow.ScriptWorkflowFunction]: Script function failed on issue: IT-2793, actionId: 1, file: <inline script>
groovy.lang.MissingPropertyException: No such property: event for class: Script5
 at Script5.run(Script5.groovy:14)

James_Mclellan

Are you using script listener? Event should be a default property.

Andreas Lärkfeldt

Hello there,

There is actually a solution (after a lot of investigations).

However you can't use the easy Edit fields in Automations - but you can use Additional fields in More options once you've added the New action component (Edit Issue).

Use the following JSON and replace the ID of the specific user:
[quote]

{
"update": {
"Request participants" : [ {
"remove": {
"id":"5e847f98dde1d52c1def9af9"
}
}],
"customfield_10071" : [ {
"remove": {
"id":"5e847f98dde1d52c1def9af9"
}
}
]
}
}

[/quote]

To also help you with how you access the user ID - go to User Management and find the specific user you would like to remove from Request Participant (or similar field). Click the user and look in the navigationbar and look for /users/ ... the string after that is the UserID.

Also - IMPORTANT!

You have to give that specific user the correct user rights within that specific project - I've given a group the user right Service Desk Customer - which doesn't charge a licens (if you don't want to).

AND make sure the rule is triggered. I've choosen "Value changed for Request Participant" - because it didn't work on issue created cause we're also using Email This Issue to add users to Request Participants.

And to help out even further - you can see how the rule is setup in attached image.

I hope this helps!

Andreas Lärkfeldt

Didn't mention, but if you would rather want to ADD Request Participants, then change Remove to Add

Rosa M Fossi

You have to give that specific user the correct user rights within that specific project - I've given a group the user right Service Desk Customer - which doesn't charge a licens (if you don't want to).

Just a caution: Tread cautiously if adding agents as Service Desk Customers. I believe this has notification implications (if the "Customer Notifications" scheme is very limited/restricted, and the agent is part of the ticket, they may find themselves missing notifications since the more restrictive scheme will be applied).

Andreas Lärkfeldt

Agree - never add Agents as Service Desk Customer!

Except from what is mentioned by @Rosa M Fossi this could also be a problem if you're using automations to transition issues on comments. Depending on the conditions given within the automation - you don't want to mixup "commented by service desk agent/service desk customer".

To clearify our usercase.

We use Email This Issue to collect issues from multiple email accounts to only one Service Desk project. I'm a huge fan of ONLY using one way in for ALL customers, and then dispatch/show incoming issues for specific teams (cause of the lack of multiple queues within the same JSM)

When doing this we automatically use the function "Add TO/CC addresses to Request Participants" added by Email This Issue.

The problem is that our "TO" (the address where this was sent) is added to Request Participants. By responding in those scenarios a LOOP is created, and we send a new email to the original address in each response, which is not a desired scenario.

Because that we know all these "TO" addresses we have then added them all to a Group in Jira called "Incoming email addresses". These mails DON'T have a licens.

The problem now was that we can't remove a user from Request Participants if they weren't already added as a customer in that specific project - which is WHY we also added that group as Service Desk Customers.

I hope this explains why we are doing what we're doing - but feel free doing something else

AP_ij8hk4

Thanks to @Andreas Lärkfeldt for the helpful answer!

fwiw, the customfield_ ID number for 'Request participants' may or may not be different than what's listed in the example (it's slightly different in our instance). In any event, you can get the ID by using the advanced search and when you enter 'request' the cf ID should be listed adjacent to 'Request participants'.

Additionally, if you're getting email tickets and the email handle that gets used is not actually a formal user account (but is listed in the system) the ID you need for the user to remove may look something like 'qm:XXXXXXX-XXXX-XXXX-XXXX-etc'

Стальнов Сергей

Hi!

It's simple:

Stephan Stahl_eec2qy

Thanks for the hint on how to remove all RP, I think it's quite handy. But I think what the OP was asking for is removing some users from request participants, not clearing all of them.

@Andreas Lärkfeldtwas pointing to a valid solution with removing dedicated user-ids in A4J, which should do the trick.

However I still think it's better to avoid users from being added to the ticket whenever it's created, rather than having to remove them every time (afterwards!) with automation.

JETI Server/DC now has a global ignorelist (see "Adding email address exclusions": https://docs.meta-inf.hu/email-this-issue/v/email-this-issue-for-jira-server-data-center/documentation/incoming-emails/mail-handlers/next-generation-mail-handlers ). I'm unsure if this feature is implemented in JETI Cloud, too, but it's straight forward and does exactly what it's intended to: users added in this list will not be added as Request Participants.

Paul Ceronio_kpmx1s

Brilliant! This answered my question, but I admit I simply wanted to remove all the request participants

💯

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira-service-desk