Integration of User Relationship Field Permissions Module with Panels 3

FWIW the entry point for applying privacy controls in user_relationship_field_perms.module is

/**
 * Mark fields private if they are not accessible by viewing user
 *
 * @param unknown_type $node node to process - each field will be marked with "#access" => FALSE if it is inaccessible
 * @param unknown_type $viewer viewing user's object, or NULL if current user
 * @param unknown_type $unknown_viewer = set to TRUE to only let publicly visible fields, i.e. viewer is not known at this time (e.g. search indexing)
 */
function _user_relationship_field_perms_apply_access_control(&$node, $viewer = NULL, $unknown_viewer = FALSE) {
...
}

which operates on a node object. Thanks.

From what alex.k says it seems like the issue revolves around the fact that his module is based on node_view where as the panels 3 override of the user profile page is based on the user view.

It appears that the actual problem is that the fields content type doesn't perform a node_view but instead calls $output = content_view_field($field, $node); directly.

We can talk about this here, but ultimately I don't think that this is something that will be fixed in Panels, but needs to be fixed in CCK, where the field is being displayed, since that's supplying the plugin for the field. That said, the root cause is that CCK doesn't provide a good centralized access control mechanism.

How does this work for Views? CCK provides that data without calling node_view either, so clearly there is a secondary mechanism for providing access control. What mechanism is that?

How does this work for Views? CCK provides that data without calling node_view either, so clearly there is a secondary mechanism for providing access control. What mechanism is that?

Thanks for bringing this up. Views has a hook_views_access_callback() for this purpose, which CCK implements in content_permissions.module:

/**
 *  The default field access callback. Remove inaccessible fields from Views.
 *
 * @see content_views_field_views_data().
 */
function content_views_access_callback($field) {
  return user_access('view '. $field['field_name']);
}

Unfortunately it doesn't supply information about the node, which is why it isn't always useful.

Ok, so your access restriction depends both upon the field, the viewer, and the actual node object? So simply calling content_access() would not be enough?

If this is the case, I think we may need to involve yched here and expand content_view_field() to allow this kind of restriction. content_view_field() is actually used with both Views and Panels, I believe, and it could be possible to kill two birds with one stone by simply adding a hook in there that could allow access to be denied there. The issue is that it still won't work nicely with content_access() which is the *real* problem -- content_access() doesn't use the node at all.

Marking htis postponed until the CCK side of this is worked out. I'm not at all sure what to do there and am going to leave that up to CCK experts.

This issue is incredibly old, with no real progress for a really long time. With most people having turned their eye's to D7 now, I'm closing this issue. If you have a real need for this, you are free to open it, preferably pointing to relevant CCK discussion.