Add new permission to view user email field

I don't think we can get away with re-using an existing permission, wouldn't this mean a possibly unwanted disclosure on existing sites?

Good catch @tstoeckler! Just imagine you have patched drupal.org with this patch. Everyone can access profiles, but noone can and should see the actual registered mail address.

Yes, I think an additional permission should be fine in terms of backwards compatibility.

This could easily be done in contrib with hook_entity_field_access and a new custom permission.

I dont think this is necessary in core.

but what about those users

Employ someone who can. It only has to be done once, as a contrib module. Something like Field Permissions, if it does not already handle base fields.

We dont need a permission in core for everything. People already complain of permission [page] bloat.

Closing this since the related issue is dealing with the underlying problem. With the change in that issue, developers can grant field-level access to User fields via hook_entity_field_access().

When upgrading to 8.6, this patch throws a Composer error.

The patch for Drupal 8.6 in case anyone needs it :-)

Valid feature request. Crosslinking SO: https://drupal.stackexchange.com/questions/205285/how-do-i-allow-regular...

Both patches do not add a corresponding permission so NW.

As @dawehner and @tstoeckler concluded, this needs a new permission.
Simple patch flying in that implements this.

I just tried the patch from #20 and it worked great! Made the changes to the two files, then went to Permissions to select the new correspnding checkboxes that appeared.

My test was on a View that displays all users. Admins could see every user's email address, but other registered users couldn't and I wanted them to. Once I added the new permission for one user type, the user table on the View immediately showed user email addresses, as promised. I then logged out and back in as another user role to whom I'd not given the permission, and that user still could not see the email addresses.
In brief, it worked as expected with a positive and negative test.

Thanks @axel.rutz.
(I'm not sure how to officially document this though.)

#20 Works for me!
You can add my D8.6.7 Intranet project to the list of successful, & very pleased, benefactors of this patch.
Thanks for leading the charge, Stephen! :-)

+1 to this request.

#20 seems to work fine. Would love to see this included sooner than later?

Sure would be nice if this were also added as a "field" so it could be included on the user profile page...

Outside of hardcore security testing, I'd say it's good to go. Let's get this small QoL detail added to core :-)

Employ someone who can. It only has to be done once, as a contrib module. Something like Field Permissions, if it does not already handle base fields.

This is why the Drupal 8 adoption curve is horrible.

#20 does not apply on 8.7 for me.

Updated the patch to apply to drupal 8.7

Fixing an indentation error in the last patch.

#31 works on 8.7.1.

Add test coverage for #31

2799049-34-TEST-ONLY.patch should fail
2799049-34.patch should pass

Helps to post the right patch.
In this patch: the failing test from #34 + the fix from #31

works on 8.7.5

A change notice is probably needed for a change such as this..

I've tested the patch in #2799049-37: Add new permission to view user email field and can confirm that it applies cleanly to 8.7.5.

It provides the expected functionality:

- Add the "view user mail field" permission that is disabled for all roles except administrator by default and can be enabled for any other user role.
- Once this permission is enabled for a user role other than administrator, the user mail field is accessible by that role.
- When the permission is removed for a user role, any user with that role is no longer able to access the user mail field.

The Change record is published ;)

As a bonus this screenshot for documentation:

RTBC again per #41

- Use createMock() instead of getMock() in UserAccessControlHandlerTest
- Add authViewer property to the test class

My interdiff generator is choking, so apologies for the old fashioned diff.

Back to Needs Review for good measure.

Looked into the interdiff of #43 and i can confirm this is a trivial replacement of a deprecated method by the undeprecated.
Tests pass. So back to RTBC as of #38 and #41.

Looks good! 👍

But we're forgetting about the API-First impact here. \Drupal\Tests\jsonapi\Functional\UserTest::testGetMailFieldOnlyVisibleToOwner() specifically is testing that the mail field is only ever visible to the owner. We need to expand that test coverage: we need to check that when this new permission is granted, that non-owners also can see the mail field.

(After that's done, we also need to expand the test coverage in UserTest::testCollectionFilterAccess(). That may be trickier. Let's start with ::testGetMailFieldOnlyVisibleToOwner().)

Sorry to kick this back to Needs work 😔 I promise I'll provide reviews!

Reroll the patch to work on the latest version

Before I work on the tests as per #45, I thought I could simplify the patch and update the comments for the new permission. Doing that here.

+++ b/core/modules/user/src/UserAccessControlHandler.php
@@ -120,6 +120,9 @@ protected function checkFieldAccess($operation, FieldDefinitionInterface $field_
+          if ($field_definition->getName() === 'mail' && $account->hasPermission('view user mail field')) {
+            return AccessResult::allowed()->cachePerPermissions();
+          }
           return AccessResult::allowedIf($is_own_account)->cachePerUser();

There is also a repeated check in this if condition. The outer switch block already checks this. So, this can be removed. Once we remove this, there is only one conditiion which means we can collapse this 4 lines into a ternary operator.

Also, I am not sure why the reroll in #46 was necessary. The patch in #43 applied cleanly for me on 8.8.x.

Ah, I missed the falling switch. Disregard the patch in #47. I am just changing the comment now.

Adding one of the tests mentioned by @Wim Leers in #45.

I can see the permissions coming up correctly in 8.7 core but on of the test hunks failed. So the logic is working.

Patch #46 works for 8.7 branch

Patch #50 doesn't cleanly apply to 8.7.8 (one chunk fails to be inserted automatically), but - when applied manually - works like a charm.

Also, I want to chip in, that my company is doing a lot of project websites for European Commission or federal ministries. And they always need some internal area where the partners (often distributed throughout all of Europe) are listed with their contact information.

This is the code that doesn't get inserted automatically when trying to apply the patch:

@@ -96,6 +103,18 @@ protected function setUp() {
       ->method('hasPermission')
       ->will($this->returnValue(TRUE));
 
+    $this->authViewer = $this->createMock('\Drupal\Core\Session\AccountInterface');
+    $this->authViewer
+      ->expects($this->any())
+      ->method('hasPermission')
+      ->will($this->returnValueMap([
+        ['view user mail field', TRUE],
+      ]));
+    $this->authViewer
+      ->expects($this->any())
+      ->method('id')
+      ->will($this->returnValue(3));
+
     $entity_type = $this->createMock('Drupal\Core\Entity\EntityTypeInterface');
 
     $this->accessControlHandler = new UserAccessControlHandler($entity_type);

Edit: I rerolled the patch, but this was my mistake. This reroll isn't relevant.

The patch works for me when applied manually as well.

Patch from #46 applied successfully and works as expected

Hi,

I have reviewed the patch #55 and it worked as design.

Below are my updates after applying the patch.

1). it had added the one permission "View user mail field".

2). I have made one role "email test" and one view that is showing an email address.

3). I have given permission("View user mail field") to the role "email test".

4). And the user who has the role "email test" was able to see the email of another user.

So, the patch is working great.

Below is the output screenshot of the test result.

Thanks,
Ren

#55 is failing on 8.7.11

Hunk #1 succeeded at 410 (offset 3 lines).
patching file core/modules/user/src/UserAccessControlHandler.php
patching file core/modules/user/tests/src/Unit/UserAccessControlHandlerTest.php
Hunk #2 FAILED at 103.
1 out of 3 hunks FAILED -- saving rejects to file core/modules/user/tests/src/Unit/UserAccessControlHandlerTest.php.rej
patching file core/modules/user/user.permissions.yml

1. +++ b/core/modules/user/tests/src/Unit/UserAccessControlHandlerTest.php
   @@ -240,6 +259,26 @@ public function hiddenUserSettingsProvider() {
   +      if ($field == 'mail') {
   +        $access_info[] = [
   +          'field' => $field,
   +          'viewer' => 'authViewer',
   +          'target' => 'owner',
   +          'view' => TRUE,
   +          // See note above.
   +          'edit' => TRUE,
   +        ];
   +      }
   +      else {
   +        $access_info[] = [
   +          'field' => $field,
   +          'viewer' => 'authViewer',
   +          'target' => 'owner',
   +          'view' => FALSE,
   +          // See note above.
   +          'edit' => TRUE,
   +        ];
   +      }
        }
   

   This can be written as

         $access_info[] = [
           'field' => $field,
           'viewer' => 'authViewer',
           'target' => 'owner',
           'view' => $field === 'mail',
           // See note above.
           'edit' => TRUE,
         ];
   

   Also for test clarity I suggest change "authViewer" to "emailViewer" as this really means a viewer with permission to view emails.

2. +++ b/core/modules/user/user.permissions.yml
   @@ -11,6 +11,8 @@ administer users:
   +view user mail field:
   +  title: 'View user mail field'
   

   I do think the issue so far has no really answered the question "Is this really supposed to be in core?" - there are modules like field_permissions that might be installable and allow you to configured this through the UI. And there's the other issue that incorrectly setting this allows for unintended information exposure. It would be great to see some thinking around this part. Perhaps the permission needs to warn about information disclosure more - I don't know.

Points covered in patch as suggested in #60.

@Hardik_Patel_12 it's a great idea to run tests that you change before updating a patch. That way you know whether your changes are good if all you are changing is a test.

+++ b/core/modules/user/tests/src/Unit/UserAccessControlHandlerTest.php
@@ -32,6 +32,13 @@ class UserAccessControlHandlerTest extends UnitTestCase {
+  /**
+   * The mock user account with 'view user mail field' permission.
+   *
+   * @var \Drupal\Core\Session\AccountInterface
+   */
+  protected $authViewer;

@@ -96,6 +103,18 @@ protected function setUp() {
+    $this->authViewer = $this->createMock('\Drupal\Core\Session\AccountInterface');
+    $this->authViewer
+      ->expects($this->any())
+      ->method('hasPermission')
+      ->will($this->returnValueMap([
+        ['view user mail field', TRUE],
+      ]));
+    $this->authViewer
+      ->expects($this->any())
+      ->method('id')
+      ->will($this->returnValue(3));

In order for the test to work the property name needs to be $emailViewer too...

The use case is "some sites want extra permission over who can see an account's email address outside of that specific user and user admins". Why does this need to be in core rather than an optional download?

The purpose of a modular system is that addons can handle specific use cases not provided by core, not to pile on every feature into core that any site ever might need. I don't understand why there's pushback on this concept.

We already have the Field Permissions module available to theoretically handle this scenario, IMHO this should be "closed (won't fix)".

Agree with @DamienMcKenna or create a tiny contributed module if applicable, such as user_mail_permission.

#23: I'm still hopeful to see this put into core to help promote Drupal in the 'Intranet' space.

But from the perspective of promoting Drupal, I'd vote to "LET'S DO IT", a learner or newcomer may not know the existence of the field_permissions module and use it, and field_permissions is a little heavy, if just for this use case.

I reviewed Field Permissions and it doesn't currently support the mail field because, as the maintainer said:

Unfortunately, since mail is a base field, this module cannot control access to it. This module simply leverages hook_entity_field_access(), which isn't called at all for entity base fields (as far as I know).

I suggest folks looking for this put together a small contributed module to inject this permission into the user system to control access to that base field.

@drumm from the security team made an excellent point in favour of this change

It could mean less people have admin users, which was granted just to let people see email addresses. That’s definitely good. Some of the core permissions can be coarse enough to get you into granting more than you need.

I am in favour of this change too. While it might be possible to do this in a contrib module, the scope of the permission just feels right to be in the core. I think sites which expose an API with user data commonly need this.

Fixed and refactored UserAccessControlHandlerTest.

Omitted expects($this->any()) which is by default, and updated assertions, such as

-      ->will($this->returnValue(FALSE));
+      ->willReturn(FALSE);

$context_tokens is a required argument of CacheContextsManager::assertValidTokens()

   * @param mixed $context_tokens
   *   Variable to be examined - should be array of context_tokens.
   *
   * @return bool
   *   TRUE if context_tokens is an array of valid tokens.
   */
  public function assertValidTokens($context_tokens) {

-     $cache_contexts_manager->assertValidTokens()->willReturn(TRUE);
+     $cache_contexts_manager->assertValidTokens(Argument::type('array'))->willReturn(TRUE);

I have some more live use cases where this is needed:

We used this in several sites for small communities where every member sees the list of contact data of all other members. Those communities usually have neither funds nor php folks nor core committers but constitute a important part of Drupal's long tail.

Another use case i encountered is getting user data via json:api into a remote system. Without this permission it is impossible for the api user to have full read access on users without getting further permissions. (Note this issue has Api-First Initiative tag.)

1. +++ b/core/modules/jsonapi/tests/src/Functional/UserTest.php
   @@ -412,6 +412,18 @@ public function testGetMailFieldOnlyVisibleToOwner() {
   +    // Viewing user A as user B: "mail" field should be inaccessible.
   ...
   +    $this->assertArrayHasKey('mail', $doc['data']['attributes']);
   

   I believe the comment wants to say "should be accessible". ;)

2. +++ b/core/modules/user/tests/src/Unit/UserAccessControlHandlerTest.php
   @@ -68,50 +76,54 @@ protected function setUp() {
        $this->viewer = $this->createMock('\Drupal\Core\Session\AccountInterface');
        $this->viewer
   -      ->expects($this->any())
          ->method('hasPermission')
   -      ->will($this->returnValue(FALSE));
   +      ->willReturn(FALSE);
        $this->viewer
   -      ->expects($this->any())
          ->method('id')
   -      ->will($this->returnValue(1));
   +      ->willReturn(1);
   

   Totally unfamiliar with this test, but on reading the patch, these changes seem unrelated and out of scope. What's going on here?

   Same concern on nearly all of the changes to all of the tests in this patch. ;)

3. +++ b/core/modules/user/user.permissions.yml
   @@ -11,6 +11,8 @@ administer users:
   +view user mail field:
   +  title: 'View user mail field'
   

   Do we want 'restrict access: true' for this one? Kinda on the fence. If we use that flag too much, people will tune it out. OTOH, giving this out too broadly would be info disclosure.

   As a compromise (and probably worth doing, regardless) can we rename the new permission to something a bit more scary and self-documenting like "View all user mail fields" or something?

NW for at least point 1. I'd love feedback on points 2 and 3 before RTBC.

Thanks,
-Derek

+++ b/core/modules/jsonapi/tests/src/Functional/UserTest.php
+++ b/core/modules/jsonapi/tests/src/Functional/UserTest.php
@@ -412,6 +412,18 @@ public function testGetMailFieldOnlyVisibleToOwner() {

Probably out of scope, but should we rename this test method given the changes to what it asserts?

Thank you, @dww for reviewing.

Instead of continuing working on my previous patch, started from #61 again to avoid unnecessary changes/refactoring which might make review harder.

Changes made:

1. Renamed $authViewer ($this->authViewer) to $emailViewer ($this->emailViewer) to get the CI errors fixed in #61.
2. Change inaccessible to accessible to address #71.1
3. Added restrict access: true to user.permissions.yml addressed #17.3

#17.2 and #18, keep them untouched unless have to. it's about code refactoring.

I have checked patch from #73 on my website, and it works for me.
Permission appears, user with this permission can see email.

Re: #73 - thanks, @jungle!

I'm not sure adding 'restrict access: true' is the right move, but I wanted us to consider it. I think this might be more useful (#71.3):

As a compromise (and probably worth doing, regardless) can we rename the new permission to something a bit more scary and self-documenting like "View all user mail fields" or something?

Agree-to-disagree with the "add this to a contrib" school of thought, I don't understand why this isn't in core.

So if we want to use Drupal as a member or directory site, we should install a bunch of contrib modules to make that happen? All I needed was a way to expose email on a directory list made from a view.

I do understand how this can be a bad permission if it isn't well thought out, but so can "Bypass content access control" which I have had to do in the past because it was flat out easier to grant than trying to track down some xyz contrib module that gave more granular control.

"If" Drupal is now supposed to be some fancy Enterprise OpenSource software, wouldn't it make more sense that more and more "companies" would use it for personnel collection and display? I'm just playing devils advocate here, but I keep hearing how Drupal is going after Enterprise, which means email is a pretty big concern for enterprises to expose if they're using Drupal as an internal tool... Right? So wouldn't core want to cater to the main demographic target? Just sayin...

#73 works great on 8.8.5 BTW. Thanks for the work on pushing this forward.

Patch #73 works in 8.9.2. Great thanks to @jungle!
Crazy that this isn't a part of core already.

The permission description says, "Warning: Give to trusted roles only; this permission has security implications."

What security implications are there if the mail field value is visible to anonymous users?

I understand there are privacy issues, but if a user chooses to make their email address public and the email address is obfuscated, what else is there to be concerned about?

Yes, I'm waiting for this too. It would be much appreciated.

1. +++ b/core/modules/user/src/UserAccessControlHandler.php
   @@ -117,9 +117,12 @@ protected function checkFieldAccess($operation, FieldDefinitionInterface $field_
          case 'preferred_admin_langcode':
          case 'timezone':
          case 'mail':
   ...
   +          if ($field_definition->getName() === 'mail' && $account->hasPermission('view user mail field')) {
   

   Instead of first bunching in mail with some other options and then doing an if() on the same key that the switch uses, wouldn't it be clearer to just give mail its own group in the switch?

2. +++ b/core/modules/user/tests/src/Unit/UserAccessControlHandlerTest.php
   --- a/core/modules/user/user.permissions.yml
   +++ b/core/modules/user/user.permissions.yml
   
   +++ b/core/modules/user/user.permissions.yml
   @@ -11,6 +11,9 @@ administer users:
    access user profiles:
   ...
   +  restrict access: true
   

   Yeah, adding 'restrict access' seems like a bit much here, I like the suggestion to make it a little more scary, or maybe add a description? "This permission may have privacy implications."

Since we don't have this in core yet, I went ahead and created this small contrib module: https://www.drupal.org/project/view_user_email

I've taken the feedback from #75 and #82 and merged that into a new patch. I too hope that this can become a part of core.

Changes:

1. The permission is now called 'access user mail'. Core uses 'access *' permissions everywhere for all view operations, so 'view user mail field' felt out of place. This can cause issues for existing patch users when switching to the new version of the patch, but let's keep core consistent right?
2. #82.1 Logic has been changed and mail is moved above the existing block, making use of case fall-through for the cases of viewing the own account or editing. (Documented to make that more clear.)
3. #82.2 Restrict access removed and replaced with the description 'View email addresses of all other user accounts.'. That should make people at least think twice.
4. In #73.2 the wrong 'inaccessible' was mistakenly changed to 'accessible' (line 404). Accessible should be on line 418 after granting the perimssion. This has been corrected

Hoping this addresses all issues.

If people agree on the permission name change, the draft change record will need another update.

That seems unrelated. Switching to needs review.

Patch#84 is working fine for all the issues mentioned under comment#84. +1 for RTBC.
Screenshot is attached

Steps:

1. Visit /admin/people
2. Create users with moderator and authenticated role.
3. Provide "View user email" permission to moderator.
3. As an admin, create a view with permission "View user email"
4. Also enable email fields on view.
5. Email address of all the users available will be visible to moderator but not to authenticated users.

Tested #84, working fine on 9.1
This can be moved to RTBC

The change record has been updated.

Then please allow me to RTBC my own patch on behalf of Ruchi Joshi and tanubansal who both RTBC'd +1.

 .../jsonapi/tests/src/Functional/UserTest.php      | 12 ++++++++++
 core/modules/user/src/UserAccessControlHandler.php |  8 ++++++-
 .../src/Unit/UserAccessControlHandlerTest.php      | 27 ++++++++++++++++++++++
 core/modules/user/user.permissions.yml             |  3 +++
 4 files changed, 49 insertions(+), 1 deletion(-)

Looks irrelevant

That is the summary of the patch? Won't make it into the code base.

Removed the unused use statement.

Not sure how that ended up there, but thanks for spotting it. Considering the minor change and the functioning already confirmed by #88 and #89. I am setting this back to RTBC.

'access user mail' seems potentially misleading in that it looks like it will allow you to access their e-mail (which is not impossible with messaging or e-mail digestion modules). Not entirely sure what we could use instead - tagging for usability review.

Bumping this back to CNR until we get some more usability feedback.

How about "Last access" info?

I would rather see this get added as-is with a new issue created to discuss renaming the "access user email" nomenclature.

Let that issue live in discussion for the next 5 years so we can all at the very least have the functionality of what this patch proposes.

This issue is already over 4 years old. It's done and works. If no-one has any issues with the misleading code in the next month or two, let's put it to rest before the tests require something different that cause it to fail and put it back to square 1. I'm tired of having to remember to re-patch my sites.

I did the name change in #84 (by now I wish I had not), but I still somewhat think that this name makes sense for the permission, because it is in line with the rest of core.

As for the usability aspect, I've changed the permission label to 'Access user email addresses'. That should remove all possible confusion and be backwards compatible with everybody using this patch.

Could we please get it in now?

@Neograph734 You may increase chances if you provide an interdiff.

@geek-merlin, thanks for the feedback. I had thought about it, but an interdiff for one word felt quite useless... So I decided to write in the message content what I changed. (But I can imagine that is easily overlooked.)

To enhance usability, the permission label has been changed to highlight it is about email addresses only.

Patch from #94:

+access user mail:
+  title: 'View user email'
+  description: 'View email addresses of all other user accounts.'

Patch from #101:

+access user mail:
+  title: 'View user email addresses'
+  description: 'View email addresses of all other user accounts.'

As for the system name of the permission; that follows the pattern 'access [entity-type] [field]' used throughout core, for which I still believe it makes sense.

Applied patch #101 on 9.2.x.The patch is working fine.

After patch:

New permission shown

Permission checked view:

Permission unchecked view:

RTBC +1

We discussed this issue at #3195727: Drupal Usability Meeting 2021-02-05 and again at #3197014: Drupal Usability Meeting 2021-02-12.

We agreed that the description has to say more. The current text ("all other user accounts") suggests that this permission gives access to some sort of directory where all users are listed with their e-mail addresses. That is not what it does!

We need to make clear that this permission only applies to pages where the e-mail address is (optionally) rendered. Also, it is not limited to "pages": if the JSON:API module is enabled, then the permission affects the fields exposed to the API.

Something like this:

Wherever user email addresses are shown, including Views and JSON:API, they will only be shown to users who have this permission.

Maybe it would be clearer to describe what happens for users who do not have this permission: something like

Users without this permission will not have access to email addresses on user pages or other places where they might be shown, such as Views and JSON:API.

Is that an accurate description?

@benjifisher Thank you for the review.
I believe the second one looks more appropriate.

Users without this permission will not have access to email addresses on user pages or other places where they might be shown, such as Views and JSON:API.

That looks good and accurate for what the permission does. However (English not being my primary language), I'd say 'JSON:API' does not fit nicely in a 'listing of places'.

IMO it would be better to use 'API response' (making it more or less a place again). So then it becomes:

Users without this permission will not have access to email addresses on user pages or other places where they might be shown, such as Views and JSON:API responses.

Perhaps a native speaker can help out here?
Would it require a new patch or can this be changed during commit? It is only the description of a permission.

Implemented usability feedback from #105 and my addition from #107.

As for the change record, it now states the permission is view user email, but the system name is access user mail. I think that could be enhanced. Also the screenshot could do with an update with the new long description?

CR updated.

Status was changed in #98 because of usability. This has been addressed in the recent patch (only a change in a label and nothing functional).

Back to RTBC.

Looked through this again.

I think there is still a small potential for confusion where a user doesn't have this permission, but is able to see user's e-mail address because they have 'edit all users' permission. However it's not the only case where we have permission crossover like this, and requiring both to edit e-mail addresses would be a signficant change with bc implications.

I do agree that this is somewhat of a borderline feature for core given that it's doable from contrib, however there are enough separate use-cases that it seems reasonable to add, as well as support for the security team since it can discourage over-granting permissions.

So.. Committed 84c8b1e and pushed to 9.2.x. Thanks!

Sorry I thought about this overnight and I think the new permission name is still confusing: 'access user mail' still feels like reading e-mails, not viewing e-mail addresses.

'access user email addresses' might be clearer, even though it's a bit longer?

Reverted for now - an issue summary update would still be useful here too.

Agreed, it totally sounds like that! My preference would be to use ‘view user email addresses’ rather than use the word ‘access’ but that would be a totally unnecessary bikeshed diversion :-)

I imagine concise strings are preferred, but I don’t think there will be one any more concise than 4 words.

Per #71.3, I agree the name as originally committed wasn't great. At that point, I suggested "View all user mail fields" but that's not good.

+1 to "access user email addresses", that seems very clear and self-documenting.

Actually 'view user email addresses' is a lot better, since that's the access $operation, whereas access is a concept that could also mean edit. Updating the issue summary with that.

When I wrote #84 I did a check and throughout core there are so many 'access *' permissions that for as far I could see only granted view access.
It felt like the best match and a name that is consistent with the rest.

'view user email addresses' is a good name too. Better even, and if the consistency of permission names is less importance than a potential misleading name this feels like a good move.

Re-roll for 'view user email addresses'. Further proof this is the right solution (from the interdiff):

-access user mail:
+view user email addresses:
   title: 'View user email addresses'

Now the machine name matches the label. Good sign! ;)

Also, fixed the release note snippet to match, so I don't think we need any more summary edits.

Thanks!
-Derek

#RandomFail: #3191559: [random test failure] Random test fail in EntityReferenceWidgetTest

1) Drupal\Tests\media_library\FunctionalJavascript\EntityReferenceWidgetTest::testWidget
Behat\Mink\Exception\ElementNotFoundException: Button with id|name|title|alt|value "Show media item weights" not found.

Re-queued and back to NR.

+1 to 'view user email addresses', it describes precisely what the permission allows, I don't think we can make it any shorter without losing some meaning or being confusing.

Thanks for the quick turnaround, glad I thought about this more after committing it now...

Committed 6e137b3 and pushed to 9.2.x. Thanks!

Tagging for release note mention. The snippet is already in the issue summary, thanks for that!

@catch clarified to me that this should be a highlight, not a release note, because there's no risk of it breaking anything on existing sites.

Applied the patch from #119 to drupal/core:8.9.14 with composer without any issue.
After adding the new permission view user email addresses to the role's configuration, the email address would display properly.

Thanks again for contributing this feature.

I've tried the patch from #119 on D9.1.8 and it does not work. I check the box, rebuild pemissions and clear all cache, but to no use. It does not work.

The only way for me to have it working is to check Administer users

@hassebasse You could try to upgrade to 9.2. The new permission is in core now: https://www.drupal.org/node/3070293

Thank you @piridium , I will look into this later.