Make the value of e-mail field visiable on user profile's View page

[alanmels]

Description of the need

One on of the Backdrop websites a customer wanted to see e-mail addresses of users without taking an additional step (going to Edit tab).

Unfortunately, there was no option on /admin/config/people/manage/display/default to make the field appear on the View page, but it was fairly easy to satisfy such a requirement by implementing a custom template. However, I still wondered why such an option is not available via UI.

Proposed solution

I'm totally ok if it is by special design not to make the value of e-mail address field available on the View page, however if the community members would share my curiosity why it could not be made available, then this feature request could have a chance.

[argiepiano]

How about overriding the uri of the user profile page with a View and adding those fields there?

[stpaultim]

This request came in during the Design / UX meeting today and we talked about it briefly.

I believe that the reason the email is not visible is that the user page is often visible to other users, especially on community sites and I don't think we'd want to expose every users email to every other authenticated user by default.

However, there is a use case for exposing this information to site admins without requiring that they click on the edit tab. I think we'd just need to think about the best option for accomodating both of these use cases.

[alanmels]

@argiepiano, there are number of different ways of getting this done, including the one you suggested. However, the idea is to make it easy for regular users by providing such option on UI.

@stpaultim, It should not be definitely exposed by by default, but it could be made available via the field's UI option.

[argiepiano]

One approach (if there is consensus that we want to add this functionality to core) is to declare mail as part of user_field_extra_fields() (in the display sub-array), which will make it appear in the Manage Display UI for users, and then add it to the content array in user_user_view().

It's a very simple addition. But I don't know how to make it disabled by default.

To make it disabled by default, you'd need to use field_bundle_settings() and turn the visible flag off in display for the new extra field.

Perhaps this is a good contrib candidate, as the use case seems a bit limited as the general approach both in D7 and B is not to show users' emails.

[argiepiano]

I just whipped together a contrib module, User Email Display, that exposes the mail field to the Manage Display UI. It sets the mail field as hidden by default.

https://github.com/backdrop-contrib/user_mail_display

[indigoxela]

@argiepiano many thanks for that contrib module. It saves me from opposing here. 😉

Email is personal data and I don't think it's appropriate to show it. Lot's of effort has gone into hiding email addresses. Most webmasters won't want to show them. And probably most users prefer to hide them, too.

A cite from the form item description (user.module, user_account_form()):

'#description' => t('A valid email address. All emails from the system will be sent to this address. The email address is not made public and will only be used if you wish to receive a new password or wish to receive certain news or notifications by email.')

Note the "The email address is not made public...".

[stpaultim]

I don't feel strongly about this and maybe a contrib module is fine.

Email is personal data and I don't think it's appropriate to show it.

BUT, I don't think there is anything inappropriate about the request that was made here. I don't think anyone suggested that we make emails available to the public or even to other authenticated users that don't already have access to them.

Emails addresses are already available to site admins and they should be.

My understanding of this request was that if a site admin already has access to emails, why should they need to click on the edit tab to access the information. It seems to me that the EDIT tab is for editing information, not viewing. If I have access to view it, why the need to go into an edit screen.

To me, this is a perfectly reasonable request and there is no reason it couldn't go into core in a way that is very appropriate. Having said that, if we have a good contrib solution and folks are happy with that, so am I. I look forward to testing the module.

[argiepiano]

I know this is controversial. I added a note to the module saying that showing the email is not a good idea, and use at your own risk. I want to add that it's possible, with Display Suite, to show this and other properties of entities, so there is a precedent for this. This module is just much, much lighter and simpler. Also it hides it by default so that someone doesn't accidentally expose this info.

Of course is the security team thinks this module should not exist, we can kill it. And perhaps revise Display Suite too?

[argiepiano]

And one more comment re: emails. Like @alanmels, I was also asked by a client to expose emails. Instead of this, I added separate Field API field that explicitly said "This email WILL be made public" and it was optional. That way the user could enter a dummy email or a separate "spam" email there if they did not want to reveal the account email.

[indigoxela]

Instead of this, I added separate Field API field that explicitly said "This email WILL be made public" and it was optional

🎉 perfect suggestion!

I don't think the contrib module does any harm or is a security problem. I just wouldn't want this to be in core.