Permissions not working for Views fields without "administer profiles"

I don't think it's related to #1051550: users always see their own profiles -- that is to do with hook_user_view permissions, whereas Views has its own system for its fields.

Hi guys,

Have come across this issue myself where I was wanting to show a profile2 field in a view but only the admin could view it.

The below function is where viewing the field is being disallowed... as $profile is not set and therefore FALSE is returned.

function profile2_field_access($op, $field, $entity_type, $profile = NULL, $account = NULL) {
  if ($entity_type == 'profile2' && $op == 'view' && !user_access('administer profiles', $account)) {
    // For profiles, deny general view access.
    if (!isset($profile)) {
      return FALSE;
    }
    // Also deny view access, if someone else views a private field.
    $account = isset($account) ? $account : $GLOBALS['user'];
    if ($account->uid != $profile->uid && !empty($field['settings']['profile2_private'])) {
      return FALSE;
    }
  }
}

No idea where to go from here, but just thought I'd add this and subscribe at the same time.

Part of the problem was that hook_field_access is supposed to receive a $field array, whereas until #1124298-12: Views does not check hook_field_access()? was committed, only the field name was being passed. Now, $field is actually an array (in the latest Views dev). Yet, no $profile value is passed.

At this point we can figure out which bundles the field belongs to in $field['bundles']['profile2']. However, since a field could belong to multiple bundles, we don't know which profile type to load, unless there is only one bundle.

So, here's a patch which respects the "view any profile" if the field is attached to only one bundle. If the field is attached to more than one, it will deny access.

It's a start, at least. Until the $profile entity is passed, there's no way to check "view own profile" permissions.

Subscribe. Thanks, #7 worked for me.

The "private" option isn't bundle-specific, so we can just restrict access to those fields.
Patch attached. Please test.

This doesn't change the behaviour for private fields though, it's up to views to pass an entity.

I've committed that patch, please re-open if there any troubles with it.

This issue is still not solved for me in: 7.x-1.3 and in 7.x-1.x-dev.

1. I add a relationship for profile
2. I add a profile 2 field to the view
-> result is only visable for admin

Only user with the Permissions: Administer profiles see the profiles2 fields on their own profile in that view.

Just following up on this:

If, when configuring your Profile2 fields (in Profile types » [Profile Type] » Manage fields) you check the box labelled "Make the content of this field private," you will NOT be able to access these fields in Views, even when the view is configured in such a way that the view is only accessible to the owner of the profile.

This caused me no end of grief, but glad I finally figured it out after looking at some of the access patches posted. I'm posting this so that hopefully someone else will avoid the same pitfall.

This took me a long time to workout, but the basic problem is that Profile2 field permissions fail when using the "Fields" Views row style. You *can* get it working, but only by outputting the rendered entity:

This isn't ideal of course, because it means you can only manipulate these fields with php templating, custom field formatters, or DisplaySuite, but strictly speaking Profile2 fields are accessible to Views (only in a slightly inconvenient way).

Here's a patch for the above described issue.

To test this, I did the following:
1. I configured a view which shows user profile2 fields, and uses the "Fields" row style.
Result: Working as desired. Authenticated users were able to see their own fields, but not the private fields of other users. Users with the "administer profiles" permission were able to view all profile fields.

2. I configured a view which shows user profile2 fields, and uses the "Rendered Entity" row style.
Result: Identical to #1 above.

3. Logged in as a user with the role "authenticated user". I attempted to view another user's private field by navigating directly to /user/:uid/:profile_type. I was not able to view the user's private fields.

If anyone out there would like to implement this in a minimally invasive way, without patching profile2, for the time being you can create a custom module that does the following:

/**
 * Implements hook_field_access().
 */
function yourmodule_field_access($op, $field, $entity_type, $profile = NULL, $account = NULL) {
  if ($entity_type == 'profile2' && $op == 'view' && !empty($field['settings']['profile2_private']) && !user_access('administer profiles', $account)) {

    // Deny view access, if someone else views a private field.
    if (isset($profile)) {
      $account = isset($account) ? $account : $GLOBALS['user'];
      if ($account->uid != $profile->uid) {
        return FALSE;
      }
    }
  }

}

/**
 * Remove faulty field_access implementation from profile2.
 * 
 * See https://www.drupal.org/node/1149808
 */
function yourmodule_module_implements_alter(&$implementations, $hook) {
  if ($hook === 'field_access') {
    unset($implementations['profile2']);
  }
}

The patch in comment #19 worked for me.

Strange, but I missed this issue. Anyway, today I found it and tested it - patch works! Thanks MKorostoff for detailed description and for your patch. It is your second patch for profile2 module, and both times I exited about your work.

@solenity, also thank you for testing this. Without RTBC status I could not find it for quite a long time :-)

The commit actually introduced #2376123: Missing parenthese in the last dev version.

Thanks for the report. I will fix it in the related issue. Closing this one.