How to identify request participants when there are multiple people with the same name?
Asked by John Wagenman:

Our request participants are being added as expected, but there appears to be no way to identify which user was added when there are multiple users of the same name.

Why is this a problem? When we get legal holds through our system, and a participant is added that needs to be put on hold, there is no way to identify which person it is because the email is not exposed. ++If you mouse over the assignee or the requestor, those have a popup that reveal the email. The participants do not. Additionally, any email not recognized as a user is also revealed in the participants box and you can also mouse over that and it has a popup!++

For example if John Smith was added as a participant but we have 5 John Smith's. The request participant field will simply say John Smith and you can not click or hover over that to identify if it's John.Smith1, 2, 3, etc. It's also not available in the History tab as it simply lists John Smith was added.

Is there a way to make it expose the emails in the request participant field?


Answers:
author: Mikael Sandberg
body: Hi [@John Wagenman](/t5/user/viewprofilepage/user-id/5563346)

Welcome to Atlassian Community!

You can always get the Atlassian Id of the user and then use that in a JQL or automation to get issues that they are request participants on. The Id can either be retrieved manually bo going to the user's profile, the Id will be part of the URL, or you can use the [Finder users](https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-user-search/#api-rest-api-3-user-search-get) endpoint.

The email address is not exposed in the field because of GDPR.

comments: author: John Wagenman
body: Interesting. Why would we be breaking GDPR to expose our own emails in our own service desk? Perhaps if an external participant was added?

This only becomes a problem when attempting to set the hold on the user because you can't tell which one it is. Looking at the ticket, you can't click or interact with the participants in any way.

I'm beginning to think it simply isn't possible even though it seems like a simple problem.


author: John Wagenman
body: Ah! I just checked a ticket and realized that you can mouse over the assignee or the reporter and you get a popup revealing the email - just not the participants. So at least some of the emails are getting exposed, just not the ones I need. I also noticed that an email that isn't recognized as a user is also exposed.


author: John Wagenman
body: [@Mikael Sandberg](/t5/user/viewprofilepage/user-id/853579) Hello again Mikael. After looking at it last night and this morning, I noticed a couple things that I edited into my question leading me to think that it isn't a gdpr issue. Participants not recognized as users not only have their email exposed, they also have a mouse over popup revealing the same. It seems like the code is already there to do this it's just not setup to work on recognized users. Maybe only Atlassian can make the change to make that work.


author: Adolfo Casari
body: [@John Wagenman](/t5/user/viewprofilepage/user-id/5563346)maybe you can create a text customfield and have an automation rule to fill in the username-email every time the request participants field is edited.

comments: author: John Wagenman
body: Thank you. I'll see if that's something we want to attempt. Would we be able to target that to just the one kind of ticket we want it to work on?


author: Adolfo Casari
body: [@John Wagenman](/t5/user/viewprofilepage/user-id/5563346)Sure, you can set conditions on your rules, such as issue/request type.


Tags: cloud

jira-service-management

jira-service-management-cloud