Views is showing fields that should be hidden?

#1124298: Views does not check hook_field_access()?.... I believe in here, we should probably eventually return FALSE:

     // If 'view own' permission has been enabled for this field, then we can
     // check if the user has the right permission, and ownership of the object.
     if (!empty($field_permissions['view own']) && user_access('view own '. $field_name, $account)) {
   
       // When field_access('view') is invoked, it may or may not provide
       // an object. It will, almost always, except when this function is
       // invoked as a field access callback from Views, where it is used to
       // evaluate if the field can be included in the query itself. In this
       // case we should grant access. Views will invoke field_access('view')
       // again, indirectly, when rendering the fields using field_format(),
       // and this time it will provide a pseudo object that includes the
       // uid of the object author, so here is where we have the chance to
       // evaluate ownership to check for 'view own <field>' permission.
       if (!isset($object)) {
         return TRUE;
       }

... Until at least Views might eventually check field_access for individual elements.

subscribe

Subscribe.

sub

I posted a patch at #1124298-20: Views does not check hook_field_access()? which, when applied to the Views module, should fix the Field Permissions integration.

With that patch applied, there isn't much we actually need to do with the Views-integration code in this module. Mostly just adjust the code comments and remove some code that is no longer needed.

We may want to eventually make the change Rob Loach suggests in #1, but that would only be the case if #1273534: Pass entity when calling field_access happens in Views eventually. (It would be nice to do that, since the code referred to in that comment is a little weird, but as mentioned above it doesn't seem to be necessary to fix the main problem.)

The patch here is rolled on top of #1279712: Revamp the Field Permissions user interface to make it more intuitive (i.e., only applies after that one has been committed) since the expectation is that will go in relatively soon and it didn't seem worth the effort to have to reroll the patch again.

We can actually modify this slightly to improve the experience in the case of private fields.

When a private field is specifically included in a View, it makes sense to allow privileged site administrators to access it as part of the View (even though we normally deny view access when it is shown as part of an entity since we don't want sensitive content randomly and unexpectedly showing up in random places around the site, even for admins).

This idea was discussed at one point in #1279712: Revamp the Field Permissions user interface to make it more intuitive and is now implemented in the attached.

Going to leave this for a while for some internal testing before alpha2 comes out.... http://drupalcode.org/project/field_permissions.git/commit/83da13a

Hi, I am using the 7.x-1.0-beta2 and having the same problem. dose this patch is also for this version ?

any idea if this issue has been resolved? it also came up in the views hacks module issues queue, but seems to me to be something that should be a core component of field permissions because FP is exposed to views - but maybe that's just my opinion - perhaps it could be exposed as a conditional (contextual relationship of some kind? anybody doing it this way?)

In my case the field is hidden.

But it should not be hidden, when the view has 'role access' permission and not 'view content' permission, since this should overwrite any other permission.

Should a seperate issue be opened for this?

retracting my comment

Patch from #6 no longer applies and the code looks completely different now.

EDIT: The module works correctly even without the patch.

@milos.kroulik:
That is because this issue has been marked as fixed, which means that patch has been committed to the module.