Remove "Request Participants" using Automation rule?

[Vasumathi Jayakumar]

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 !

[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 :D (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 :D

[James Frank]

This is genius. Totally worked for me. I did not have to add the users as service desk agents. I just had to find their ID in the "people" section of Atlassian.

You can create a branching rule to handle multiple different removals in a single automation rule.

[Stephan Stahl]

@Andreas LärkfeldtI'm using E-Mail This Issue in a similar scenario, but I think "avoiding addresses to be saved as request participants" can be solved using a different approach with builtin functionality of JETI:

On the "Manage senders and recipients" part of JETI, there's an "exclusions" tab. All addresses added there will not be stored as request participants and - as the name says - be excluded/ignored (thus avoiding the "to"-scenario loop you mentioned).

We use this functionality to remove "unwanted CCs / request participants", also in order to avoid mail loops. Our first address on the exclusion list is obviously the address of the incoming mail-account.

Sadly this only works if you're using JETI ;-) - sorry Vasumathi for not adding more input to the original request.

I'm yet waiting for a "global exclusion list" for these addresses, since we're using more than one Mail-Handler which should all listen to the same exclusion list... (the copy & paste work can become rather tedious.)

[Andreas Lärkfeldt]

Thank you @Stephan Stahl

Your solution is of course better in our scenario and I will reinforce it right away (easier to maintain).

Thank you once again :D

[Andreas Lärkfeldt]

@Stephan Stahl Sorry, but I can't find exactly what you're describing.

I've found "Hide recipiants" in "Restrictions/Recipient Restrictions", but if we add mails there there will still be mails sent out - recipiants are still "added" but "hidden":

Hide recipients

Project Roles, Groups and Fields allow you to hide certain recipient options from every screen where you can select recipients, so they can not be added as recipients in manual or automated emails. Important note: it does not mean that emails will not be sent to members of the selected roles, groups or fields.

So I guess we'll still need to remove users from those fields or is there something I'm missing?

[Stephan Stahl]

@Andreas Lärkfeldtto clarify: I think you're trying to find this configuration under "global configuration", of JETI, but this is a mailhandler-specific setting.

The following description assumes you're using the "next-gen" mailhandler:
If you open your (incoming) mailhandler, you will most likely have a "save senders and recipients" condition.

if you click this, you will be able to set different behaviours for Senders, Recipients and also the "Exclusions":

In our environment we excluded the incoming mailaddress in order to avoid "writing ourselves with every reply" because our address is set as CC on incoming mails (which would result in mail loops).

Every address added here will simply be ignored by JETI and thus not be stored/listed in the "request participants".

...sadly this requires you to update all your incoming mailhandlers, in case you want to exclude the address everywhere. (Pretty much: on every condition that holds the "save senders and recipients" trigger.) Tedious copy & paste task, but I suppose there will be a workaround from the vendor in the near future ;-)

[Andreas Lärkfeldt]

Ok @Stephan Stahl , then I think you're not on Cloud or that we at least work in some different setups - also, we're not using Next-gen (Team managed) - I will never ever do that ;)  :P (This is not how it looks like for us in JETI) - see image:

Or am I looking at the wrong place? (in which settings are you looking?)

The settings you "print screened" are not to be found when I try to edit Mail Handlers in Cloud as well:

Could it be that this functionality is only available at On Preem?

From what I can see we can't use your solution at all - sadly - so we need to use our function from above, to change Recipients after the issue have been created!

[Stephan Stahl]

@Andreas Lärkfeldtsorry for the confusion about "next-gen": the above is indeed for JSM-SERVER - I didn't get your instance is running in cloud in the first place.
As for "next gen": JETI (for JSM Server) comes with two different incoming mailhandler types: "classic" and "next gen". This obviously doesn't apply for cloud... It has nothing to do with next-gen projects for Jira, it's really just a cooincidence they're using the same names.

It seems the JETI for cloud approach is a bit different (UI-wise), but I would expect a submenu on the 'set field "original participants" to Participant Email addresses" part:

I currently don't have a cloud setup with JETI to fiddle around with, but maybe you can get this working with some if/else statement and some RegEx-Filtering as described in the documentation: https://metainf.atlassian.net/wiki/spaces/JETIC/pages/160989185/Conditions and https://metainf.atlassian.net/wiki/spaces/JETIC/pages/435519631/Global+Sender+Address+Filters

Let me know if this works, I'm curious about the cloud implementation for this now! Server seems to be a bit more flexible at the moment.

[Michael Atkins]

Has anyone else's automation rule to remove someone from Request Participants been failing recently?

[AP]

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]

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]

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

💯

[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.

[Lubos Beno]

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! 

[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.