The main concern is: Nobody (anonymous/authenticated) has the permission to see the profile of any registered user on the site, so I have UNCHECKED the View user information permission for all roles.

On my site, I have the below roles:

  • Role A
  • Role B
  • Administrator (Default)

I have a content type (Task) with many fields in addition to an "Entity reference" field (field_task_manager) referencing all the users on the site excluding "administrator" role.

I have created a view page display accessed only by "Role A" which will display some field in addition to the user id (UID) of the (field_task_manager)... so:

  • Create a view of page display and table format of fields.
  • Filter the view to show: content type (Task)
  • add all required fields.
  • add the field_task_manager field to the view
  • under the field settings, change the formatter to Entity ID
  • If logged in as super user (user:1), all seems good for me!

But if I logged in as a user of Role A and try to access the above view, I cannot see the User ID of the (field_task_manager).

but if I go ahead and CHECK again the View user information permission for all Role A, I can see now the User ID of the (field_task_manager).

However, with the View user information permission CHECKED for Role A, Now Role A can access any user account by simply going to: /user/uid and this what I don't want to happen.

REMEMBER The main concern is: Nobody (anonymous/authenticated) has the permission to see the profile of any registered user on the site.

How can I give the Role A a back end access to user information such as name, email, uid... but without giving him the ability to actually SEE the user profile page of any user ?

Or maybe I am doing something wrong here!

I think the "View user information" permission should be divided into two separated permissions:
View user profile... which will allow the selected role to view the front-end profile display of any user.
Access user information... which will allow the selected role to access the back-end information of any user. (WHITOUT GIVE HIM THE PERMISSON TO VIEW THE PROFILE)

Thank you,

Comments

C.E.A created an issue. See original summary.

Version: 8.6.10 » 8.6.x-dev

Core issues are now filed against the dev versions where changes will be made. Document the specific release you are using in your issue comment. More information about choosing a version.

Version: 8.6.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Branches prior to 8.8.x are not supported, and Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.2.x-dev

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.9 was released on December 7, 2022 and is the final full bugfix release for the Drupal 9.4.x series. Drupal 9.4.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.5.x-dev branch from now on, and new development or disruptive changes should be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.

smustgrave’s picture

Status: Active » Postponed (maintainer needs more info)
Issue tags: +Bug Smash Initiative

This came up as the daily BSI target

I tried replicating by creating a view that would have user link there. While logged in with a user without the "view user information" permission I can see the user name but can't click it to see info. Does that cover the scenario you described?