We have automation set so a customer comment will transition a ticket to 'pending support'. This is a huge issue if a reporter is sharing a ticket with our service desk agents. When they add a response comment to the reporter, JSM views it as a customer comment if that ticket was shared with them. We have automation in place to remove the agent as a participant if it's shared with them after they're already assigned to it, but we can't seem to find a solution if the ticket is shared with one of our service desk agents before it's assigned. We'd really like to see some progress made on this request.

This will be of huge help to us! 

I think the problem about this is the way how "request participants" are stored in JSM. If more than one request participant is added to your issue, this would require the automation to go through a "list of users": so basically searching for all of the users (=your service desk agents) within that list that you would like to remove. (Looping through this kind of list however is not possible with A4J as far as I know.)

There definitely is an "if"-trigger for A4J to check if a user is in the request participant field (Issue field condition: if "request participant" contains any of "User A, User B, User C"...), but no "then" trigger to remove these users. (So even if you identify the users you want to remove, there's no way to properly remove them in the next step...)

A workaround might be to use A4J and call a ScriptRunner script that cleans up the request participant field. (Basically: loop through the Request Participant list, remove the agents, and then store the remainders into the Request Participants field...)

So either ScriptRunner or a combination of A4J that triggers a small ScriptRunner script might do the trick.

Any additional input is welcome, maybe someone else has a great idea on how to solve this?

I'm going to keep adding to my questions here. This is a big fix for for us. How about a way to modify this rule so that will remove any participants added if they have the role "Service Desk Team" in the project, rather than specific to the assignee of the issue? 

IMHO the "request participant added"-notification is dangerous in most of the scenarios, but I get why you would want to have it activated.

I think the problem is that the notification is instantly being queued when an issue is created (see https://confluence.atlassian.com/jirakb/troubleshooting-slow-stuck-notification-issues-in-jira-service-management-server-1041076874.html#Troubleshootingslow/stucknotificationissuesinJira/ServiceManagementServer/DataCenter-TroubleshootingJiraBatchedNotificationmailissues ), so even if you remove the request participant directly after the ticket creation with A4J, the notification is still sitting in the queue waiting to being processed.

A possible workaround might be to delete the corresponding mail from the queue table AO_4E8AE6_NOTIF_BATCH_QUEUE, but that sounds pretty risky and I would not recommend trying that...

Instead, I would like to add a different approach:

For incoming mails, I tend to use the "Jira E-Mail This Issue"-App for all incoming mail-handling, since you can simply define far better routines / handling / rules there, also including (failed) mail logs and corresponding alarms. (You might have that app installed anyway - or how are you sending attachments to your customers? ) Within JETI, you can define how users are stored within a ticket depending on their user role, so e.g. an Agent can be added as Watcher instead of Request Participant. So every time an Agent is added "as CC" in incoming mails, the Agent will be set as Watcher, thus only receiving the internal notifications.

Edit: Since I could not add a screenshot: here's the link to the JETI documentation, illustrating what I'm talking about: 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#nextgenerationmailhandlers-savesendersandrecipientssenderrecipientsaction

Please note that the config in their screenshot is horribly wrong for this case, since they're saving the Agent as Request Participant...! Instead chose "watcher" from the dropdown there...!

This will however not solve the problem when an Agent is added via the customer portal / sharing option...

Another idea would be to deactivate the "request participant added"-builtin notification, and trying to trigger a similar notification with Automation for Jira instead. The trigger could be something like:

• WHEN issue modified
• for field "request participant"
• then check: is the user an AGENT?
  • if yes
    • then remove the agent, add him/her as watcher
  • ELSE
    • then send a mail to the added participants "you were added as request participant to the ticket XYZ-123"

The tricky part here might be getting the freshly added user's mail address (=the new request participant) and using only that in the "then"-trigger. I'm not sure if A4J will let you access this specific value, but might be worth trying. Maybe it's possible to access it with a smart value and getting that last or first object of the list...? (e.g. {{issue.Request Participant.last}} or similar might do the trick)

(That being said, the "send mail"-notification will not include your project-defined customer mail template... alternatively you could use a "then: comment"-action here, but that will spam the ticket and send the info about "someone was added to the ticket" to all members of the tickert (Reporter & Request Participants...)

I hope this helps!

I think it's not easy to solve this, but the main problem remains that agents are accidentally dragged into the "role" of a customer. There is a user role concept in JSM, I don't get why this is not being checked upon creating the corresponding (customer/internal) mail notifications. (If user role = agent > send internal notification. else send customer notification... doesn't sound too complex to me, when adding mails to the mail generation queue.)

I have an additional question here. We have our customer notifications configured to send notification when a user is added as a participant. I'd like to save our agents from being spammed when they are added as a participant, if the rule removes them just after. We have a 2minute delay on emails being sent from the tool, but the audit log looks as thought this notification is spooled to send to the agent before automation removes them from the request. Any suggestions?

I tried enabling the option to "Execute this rule immediately when the rule is triggered, instead of in the background", and that doesn't seem to prevent the notification from firing. 

This works well if the assignee is added as a request participant after being assigned to the ticket. However, do you have any guidance if the issue is unassigned and someone on the service desk team is added as a request participant? Since the trigger is the change to the request participant field, I would assume this wouldn't work if the prospective assignee is added before being officially assigned to the ticket. We see this with some of our end-users who are familiar with the support team and already know in advance who will be working the ticket. They sometimes share the ticket with the service team member who they expect will be assigned to it. Is there a way to modify this include anyone who is in the "service desk team" role on the project? 

We're experimenting with a workaround for this using Automation for Jira. The rule is triggered when the assignee of a ticket is added as a request participant. The rule checks whether the assignee field is empty or not and if its not empty it proceeds to check if the assignee is present in the request participants field. If it is it will edit the request participants and remove the assigned user. I've attached the rules as a screenshot along with the config for the last step for both Cloud and DC.

Replace the custom field ID below with the custom field ID associated with request participants in your instance.

Advanced Compare Condition Cloud
First value:

{{issue.Request Participants.accountId}}

contains second value:

{{assignee.accountId}}

Edit step Cloud:

{
"update": {
"Request participants" : [ {
"remove": {
"id":"{{assignee.accountId}}"
}
}],
"customfield_10039" : [ {
"remove": {
"id":"{{assignee.accountId}}"
}
}
]
}
}

Advanced Compare Condition Data Center
First value:

{{issue.Request Participants}}

Contains second value:

{{assignee.name}}

Edit step Data Center:

{
"update": {
"Request participants" : [ {
"remove": {
"name":"{{assignee.name}}"
}
}],
"customfield_10009" : [ {
"remove": {
"name":"{{assignee.name}}"
}
}
]
}
}

Depending on the use case you might need to adjust some of the conditions or logic of the rule but at the very least it might be a starting place as a workaround for this.

Fantastic idea that will save us so much grief!

I have the same problem. Using the automation rule to move an issue from waiting for customer to waiting for support.  Is the agent somehow gets added as a request participant (usually by being cc'ed on a mail. then when they respond to customer, the automation immediately moves the issue back to waiting for support.