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!


any user has the permission to see his own profile only and not the profiles of others as well.

There is indeed a user profile for every registered user and very well configured and on that profile there is some private fields such as phone number, ID security code* and many other... so I need only the user owner to see his own profile without have the access to see the others user profiles.

I cannot just remove the pathes of the user profiles because I need them to have every user to access his/her own profile.

Thank you,

  • Is your concern the mere existence of profile pages or just the information that can be visible there? You at least need the edit profile page otherwise how could users use their account? You can hide the fields from being displayed on the profile pages by going to Configuration > People > Account settings > Manage display. You can probably "remove" profile view paths with some custom code. – prkos Mar 7 '19 at 13:21
  • @prkos thank you for your comment, please check my update to the question... My concern is the information visible on the profile and not the existance of the profile itself – Elie Masaad Mar 7 '19 at 13:58

You should probably look into Field Permissions and Profile (it was called Profile2 in D7) to try to create the exact structure you need.

You need to keep the View user information on for Role A so they can see the necessary information on Views. Then control what is visible on the account/profile pages for particular roles.

For editing own account you might not even need the View, you only need the Edit page where users can both view/edit their info.

You can adjust which fields are visible on the View page, you can hide all if these pages aren't important in your project.

To create more control where you can view own fields but not other users' you need to set some custom field permissions.

A separate Profile page next to your Account page usually makes sense when you have a lot of user information related to the site topic, and then the usual registration login info is held in the Account as a separate page. Profile page has independent permissions so you can use that to organize your data according to access you want to achieve.

These are all different ways you can solve your problem. The exact method depends on your particular needs/project details. Look into all these options and decide which one is best suited for you.

There are, of course, even more ways how to handle this, but these are probably the most accessible and don't require custom code.

|improve this answer|||||
  • I forget to mention that I already use the "group" module and the "field permissions" module but even when with the right permissions given to ROLE A in both "field permissions" and "group permissions", the ROLE A can still NOT see the user information referenced from the "entity reference" field unless the View user information permission is ON for ROLE A. – Elie Masaad Mar 7 '19 at 15:27
  • 1
    I have come up with a solution but not sure if it will have security issues somewhere else: I was thinking to give the ROLE A the view user information permission and by using business rules module, I can create a page redirect action if the ROLE A try to access any user page with the url /user/uid/... what do you think about this solution ? is it secure enough so the ROLE A will not have direct visible access to the user account page and see private information like phone numbers and so on... – Elie Masaad Mar 7 '19 at 15:32
  • 2
    Business rules module sounds good. The security will depend on your awareness about where else you might be showing user profile data that Role A might see, and if you business rule implementation is done securely. Don't forget to exclude user's own account from the rule ;) – prkos Mar 7 '19 at 17:50
  • If you remember, the concern is to let "ROLE A" have back end access to user information like ability to see the uid of a user available in a view without have permission to access the user profile page. So I noticed few permissions like User: Administer form display, User: Administer fields, User: Administer display, do you think If I checked them and unchecked the View user information for ROLE A, it will be safe this way ? I have successfully directed any user trying to view a user profile page other than his own profile but still looking for better solution – Elie Masaad Mar 13 '19 at 14:15
  • 1
    I don't think those permissions would affect viewing the user info, they are all permissions to administer configuration. You either have to allow them to View user information to they can see them in Views, use some permissions changing code that would override this behavior (contributed or custom code), or rearrange your structure to keep sensitive data in separate "container" that you can apply custom permissions to. – prkos Mar 13 '19 at 22:01

I ran into similar problem :

  • I wanted to be able to expose user informations in a custom view, for wich I was obliged to check the "See user acount information" permission ;
  • But I didn't want my basics roles to see other user profile page (/user/{user}), wich in fact is triggered by the latter permission.

Sadly, Drupal does not have the granularity in its permissions "See own user account informations".

I solved this conflict by creating a custom route access check. See the doc :

It is a bit tidious at first glance, but quite simple in fact. After a little try and test, I succeeded like this :

Create a module, then create in your module src/Routing/RouteSubscriber.php


namespace Drupal\your_module\Routing;

use Drupal\Core\Routing\RouteSubscriberBase;
use Symfony\Component\Routing\RouteCollection;

 * Listens to the dynamic route events.
class RouteSubscriber extends RouteSubscriberBase {

   * {@inheritdoc}
  protected function alterRoutes(RouteCollection $collection) {
    // Define custom access for '/user/{user}' 
    if ($route = $collection->get('entity.user.canonical')) {
      $route->setRequirement('_custom_access', '\Drupal\your_module\Access\YourCustomAccessCheck::access');


Secondly, create at the root of your module your_module.services.yml

#File your_module.services.yml

  # custom route access check for users to profile page user/{user}
    class: Drupal\your_module\Routing\RouteSubscriber
      - { name: event_subscriber }

At last, create src/Access/YourCustomAccessCheck.php


namespace Drupal\your_module\Access;

use Drupal\Core\Session\AccountInterface;
use Drupal\Core\Access\AccessResult;
use Drupal\Core\Routing\Access\AccessInterface;

 * Checks access for displaying configuration translation page.
class YourCustomAccessCheck implements AccessInterface{

   * A custom access check.
   * @param \Drupal\Core\Session\AccountInterface $account
   *   Run access checks for this account.
   * @return \Drupal\Core\Access\AccessResultInterface
   *   The access result.
  public function access(AccountInterface $account, $user) {

    // Check if admin has "Administer users" permission.
    return AccessResult::allowedIfHasPermission($account, 'administer users')
      // Check if current user id = visited user id.
      ->orIf(AccessResult::allowedIf($user == $account->id()));


Rebuild cache, and enjoy.

I must note that I used an EventSubscriber in my services.yml and not an AccessCheck as pointed in Drupal doc (see Adding custom access checks on dynamic routes in https://www.drupal.org/docs/8/api/routing-system/altering-existing-routes-and-adding-new-routes-based-on-dynamic-ones), but I could not make it work with access_check. Maybe someone can clarify here why...

It's a lightweight solution, and I think, better than using a heavy module with plenty of functionality you do not need.

Hope it helps !

|improve this answer|||||

The easiest way to go since you have mentioned business rules module:

  1. Create a rule: Entity is viewed
  2. Create a Variable Data Comparison to check if [current-user:url:path] equal to [user:url:path]
  3. If Yes, DO NOTHING
  4. If No, Create a Page redirect action to the home page.

Hope it will help,

|improve this answer|||||
  • 1
    This what I have tried, and so far it is working as expected.... and also I have added another condition to check against if the current logged in user is with a role of "administrator" or not... If yes, he can bypass the restriction. – Elie Masaad Mar 19 '19 at 0:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.