Customer Email No Longer Visible when Hovering Over Reporter

Question

Has anyone else noticed that the reporter’s email address is no longer displayed when hovering over their name in a JSM work item?

We first noticed this change within the past few days or week. While it isn’t a deal breaker, the hover detail was very useful for quickly identifying which organization a customer belonged to based on their email domain.

This is particularly helpful because the Organizations field does not always populate automatically (a known issue we occasionally encounter in JSM).

Has anyone else seen this change? Does anyone know whether it was intentional, and is anyone else hoping Atlassian restores the email address to the reporter hover card?

Sami Shaik · Answer

Hi @Chris Green ,

@Arkadiusz Wroblewski is pointing at the right area. Let me make the model explicit, because whether an email renders on that hover card is decided by two settings stacked on top of each other, and either one can flip without anyone touching your service space.

Layer 1, the site setting. Settings, then System, then General configuration, then User email visibility. If this is set to anything other than Public or Logged in users only, emails disappear from user pickers, hover cards and the API for everyone. Atlassian's KB on this is written for the REST API but the setting governs the UI too: https://confluence.atlassian.com/jirakb/resolving-email-visibility-issues-in-jira-cloud-rest-api-responses-1528536519.html. Worth checking first, since another admin can change it in one click.

Layer 2, the account's own privacy setting. The hover card is the Atlassian profile card, and it honours the person's Profile and visibility setting for their email address ("Who can see this"). A customer with a full Atlassian account whose email is set to "Only you" will show no email to you regardless of Layer 1. Portal-only customers behave differently: they have no profile-and-visibility page, and agents can always see their email on the space's Customers page even when the card hides it.

Intentional or a regression? I could not find a published change to email visibility in the JSM changelog or the Community announcements, so I will not claim either way. What I would do: check Layer 1 first, then test with one customer you know has a full account versus one who is portal-only. If Layer 1 is open and a portal-only customer's email also vanished from the card within the last week, that is the case to raise with Atlassian Support as a possible regression, with the two account types as your evidence.

The better replacement for the workflow you lost. Inferring the organisation from the email domain by eye is exactly what JSM can now do for you:

* Organisation email domains (site level: Settings, Products, Organizations, pick the organisation, add its domains). Every new customer with that domain is added to the organisation automatically when their account is created. Doc: https://support.atlassian.com/jira-service-management-cloud/docs/use-email-domains-to-automatically-group-customers-into-organizations/. Existing customers are not back-filled, which is what step 2 is for.
* The automation template "Set organization using reporter's email domain" (space Automation, Templates), which handles existing customers on each new request and also populates the Organizations field on the request itself, so the field stops being the unreliable part. KB with both variants: https://confluence.atlassian.com/jirakb/how-to-add-jira-service-management-customers-automatically-to-organization-based-on-reporter-email-domain-1142450886.html

With those two in place you never need the email on the hover card for this purpose: the Organizations field is filled by rule, and the Customers page still shows the address when you need it for something else.

Gabriela - LeanZero · Answer

The inconsistency Arkadiusz describes has a cause that sits outside JSM, and it's separable from the question of whether something changed.

It's an account setting. Email address visibility belongs to the individual Atlassian account, not to JSM or the project, and the holder controls it at id.atlassian.com/manage-profile/profile-and-visibility, where email sits alongside profile photo, location and local time as a field they pick an audience for. So two reporters on the same project can render differently with nothing configured differently on your side. That's the expected shape.

There's a second split that matters more for what you're actually doing, because it depends on where you are looking rather than on who the customer is. In the admin screens the setting doesn't apply to you: "Your email address is always visible, no matter its visibility setting, to organization admins, user access admins and site administrators when they're managing users in the Administration screens." Inside the product it does: "Visibility settings for all other fields, including the email address field, are applied when organization admins, user access admins and site administrators collaborate with you within Atlassian apps." A work item is the second case and the user list is the first, so an address the hover card won't give you is still readable from the user list in admin.atlassian.com. Clumsier than a hover, but it survives whatever the card does.

None of that explains an address disappearing for reporters who haven't touched their own profile, which is the part you actually noticed. Only that one is a regression. The evidence that separates it cleanly is a customer whose visibility is set to Anyone and whose address still doesn't appear.

Arkadiusz Wroblewski · Answer

My too but it's not consistent.

That on a side, with this all UI changes last and this year hard to follow.