The uid of the node is not always supplied to hook_field_access()

If you need to use Content Permissions, then just grant access to all for those fields that are configured to use CCK Private Fields. The way how CCK manages field permissions works as if no one denies access to a field, then the field is accesible. So Content Permissions module should grant access, and then CCK Private Fields has the chance to deny access based on its own rules.

Since you're using User Relationships, I believe your issue might be caused by the fact the concept of *friend* could not be correctly checked by CCK Private Fields. Please, look at #542720: User Relationships is not only for Friends / Add ability to select UR relationship types. Sadly, I haven't had the time to investigate that issue, yet.

Sweet. Thanks for the feedback.

Hi,

Sorry to re-open, this works great. But anonymous user can still view fields values.

I mean :
- Everyone has 'view field_foo_bar' permission via content_permissions (anonymous and auth users)
- In a node, a user set up the Foo bar field to be hidden via CCK private fields
- In a View (display fields) the field_foo_bar value isn't shown for auth users
- In a View (display fields) the field_foo_bar value IS shown for anonymous user (same View as above)

Is there something I'm missing?

Thanks,
Jérémy

Caching issue?

Well, I've been spending some time trying to reproduce the issue, but all tests worked for me as expected.

All this stuff is based on content_access() implemented by CCK. This function invokes hook_field_access() which is what we implement here. content_access() grants access by default, and only denies access whenever any hook_field_access() implementation returns FALSE, ignoring those that return TRUE or nothing because if no one returns FALSE, access is granted. In other words, we only need one implementation of hook_field_access() returning FALSE to deny access to a particular field.

Let me number your steps above:

1) Everyone has 'view field_foo_bar' permission via content_permissions (anonymous and auth users)
2) In a node, a user set up the Foo bar field to be hidden via CCK private fields
3) In a View (display fields) the field_foo_bar value isn't shown for auth users
4) In a View (display fields) the field_foo_bar value IS shown for anonymous user (same View as above)

Regarding 1)... when you install Content Permissions, you need to explicitly grant access to fields from User Permissions Administration. So this is ok here. The hook_field_access() implementation in Content Permissions module will never return FALSE for this field (as long as anon and auth users have permission to view this field). So everyone is allowed to view this field, unless some other hook_field_access() implementation returns FALSE, which is where CCK Private Fields has its own chance to evaluate field access.
Side note: You may want to take a look at Field Permissions module, which is like Content Permissions in CCK, but a bit more easy to use and powerful at the same time. ;-)

Regarding 2) ...ok, so CCK Private Fields module should deny access to view Foo field to everyone but the node owner... OR those that have explicit 'view private data for Foo' permission.

Regarding 3) that's correct as long as users that are not the owner of the node do not have 'view private data for Foo' permission either.

Regarding 4) that's odd. Anonymous users should not be able to see Foo, unless they have 'view private data for Foo' permission. So check that too.

That's unless there is a caching issue with the view or the page.

You may want to edit includes/field_access.inc, and add prints after each step in function _cck_private_fields_field_view_access(). This should help you see a) this function is really invoked (if not, then it's probably a caching issue), and b) what it does.

Thanks for your reply!

I think I get the point.

Here's what's happening starting line 45:

// Grant access if the user account is the owner of the node.
if ($node->uid == $account->uid) {
  return TRUE;
}

I've put the following code to debug things a bit:

  if ($node->uid == $account->uid) {
    // Debugging from jchatard - start
    if ($field['field_name'] == 'field_first_name' && $node->nid == 338) {
      dpm($node);
      dpm($account);
    }
    // Debugging from jchatard - end
    return TRUE;
  }

This test condition returns TRUE, because at this specific moment, $node variable has no property 'uid' which PHP understands as 0. And for instance, an anonymous user HAS a 'uid' of '0'.

So the thing is why don't I have a "uid" in my "node" object?

I put 2 screenshots, one of my view, and one of the 2 dpm() I made in the code above.

Thanks for your help,
Much appreciated,

Jérémy

For now I can make a little hack to fetch the node uid with a simple query! But you know I don't like to hack core and/or modules that rocks!

Jérémy

Here's my little patch which solves my issue, but I think you'll have an explanation for this.

Jérémy

subscribing

@jchatard: Good catch! Thank you for the time spend on this. For some reason, I assumed the uid was going to be present in all cases, but the fact is CCK does not retrieve this field explicitly. Too bad I missed this.

I'm marking this as needs work though. We may need to retrieve the uid from the node_revisions table. I'll post a patch for review in a minute.

The patch is a bit more complex than it seems at first.

- We may need to retrieve the uid from node_revisions.
- If we cannot retrieve the uid, we should deny access to view the field for safety.
- Since we may need to add the uid to the node object, we need to clone the $node to ensure the caller's object is not altered.

Related issue in the Field Permissions module queue: #628136: The uid of the node is not always supplied to hook_field_access() (same title, different issues queue).

@markus_petrux super!

Tested with my use case, and your patch works great!

I would mark the issue as reviewed & tested by the community, but I think people should test on their installation, my case was very specific.

Thanks for your work!
Jérémy

Sweet! Thanks for the detailed reports. :)

I'll wait a little to see if someone else can provide some feedback. @trupal218?

Applied the patch on my test server as well as fresh install of drupal and everything worked great!
This is a feature I was looking into implementing and I am glad I came across this thread that fixed a potential problem I would of ran into.
side note: man, I really want to learn programming to understand what is going on in the code. starting to collect books now =)

Thanks for the great work!

Committed to CVS:

http://drupal.org/cvs?commit=287770

There are no other pending bugs in the queue, and this one worths a new release, I think. I'll do in a minute...

Thanks everyone for the great help here. Much appreciated!