Fields set to private are still found in views and search results

Working with views hasn't really been implemented yet. It's really part bug report, part new feature, so I'll marking this as a 5.x-2.x issue. It will be one of the first things done for the 2.x branch.

I had a similar problem, I dont know if the same solution will work for you, I was having users input their data via a custom content type and in the process nodes were created that I set to private, however it was still possible to access these nodes through the search, so I just set the default on the content type to create revision instead of published... now I can still access the info as an admin via a custom view... and nobody else is able to search for this anymore....

hope that helps....

Keep well,

Andre van Schalkwyk (Web Developer - South Africa)

If that doesnt work, try this module http://drupal.org/project/search_block, I havent tested it yet myself but it supposedly replaces the default search with a search that you cansetup to exclude certain content types or cck fields.

If that doesnt work, try this module http://drupal.org/project/search_block, I havent tested it yet myself but it supposedly replaces the default search with a search that you cansetup to exclude certain content types or cck fields.

If that doesnt work, try this module http://drupal.org/project/search_block, I havent tested it yet myself but it supposedly replaces the default search with a search that you cansetup to exclude certain content types or cck fields.

Hello all..
How abt the fix for views..?in a view the fields are still visible.
any suggestions,ideas.
thanks in advance..

Sorry, just haven't had the time I had hoped to work on this so far. I'll see what I can do :) Thanks for being patient! Any pointers on how to hook into views would be appreciated.

Thanks for the reply...obsidiandesign.
However still this module is really cool..Thanks for your effort to the community..
Akaash..

Hi all..i am using version = "5.x-1.1" for this module.But when i use this module in Internet explorer( IE 6.0) privacy fields do not display properly.I am not even able to select privacy fields. I assumed the bug http://drupal.org/node/230254 has already been fixed.
I even tried to apply the patch for bug but no luck.
Any suggestions,ideas...
Thanks ..

Hi got the fix..The problem is with jquery promptou. THe version of of jquery promptou has to be 1.5 which has the fix of the IE6.just replace the file from 1.2 to 1.5 and it works.
Akaash

Has this been implemented yet for views?

Thanks!

Here's my first go at this (I put this in the cck_field_privacy.module file):

TODO: Add code for filters as well...

/**
* Implementation of hook_views_pre_view().
* Removes fields from a view if a user does not have perms to view it.
*/
function cck_field_privacy_views_pre_view (&$view, &$display_id) {
global $user;
$deny = FALSE;

$fields = variable_get('cckfp_types', null);
$values = unserialize(variable_get('cckfp_values', ''));

foreach ($view->field as $key => $value) {
$term_value=split("_",$value[tablename]);
$termvalue2="";
foreach ($term_value as $key2 => $value2) {
if ($key2>1) {
if ($termvalue2!="") {
$termvalue2.="_";
}
$termvalue2.=$value2;
}
}
foreach ($fields as $key2 => $value2) {
if (is_array($values[$value2]) && array_key_exists($termvalue2,$values[$value2])) {
$deny = TRUE;
}
}
}

if ($deny==TRUE) {
foreach ($display_id as $key3 => $value3) {
$tmpclass=new stdClass();
foreach (get_object_vars($display_id[$key3]) as $key => $value) {
$term_value=split("_",$key);
if ($term_value[0]."_".$term_value[1]=="node_data") {
$termvalue2="";
foreach ($term_value as $key2 => $value2) {
if ($key2>1) {
if ($value2=="field" && $termvalue2!="") {
break;
}
if ($termvalue2!="") {
$termvalue2.="_";
}
$termvalue2.=$value2;
}
}
if (mysql_num_rows(mysql_query("select cckfp.uid from cckfp left join node on cckfp.uid=node.uid where cckfp.uid<>".$user->uid." and node.nid=".$display_id[$key3]->nid." and cckfp.field_name='".$termvalue2."' and cckfp.permission='n'"))!=0) {
$value="";
}
}
$tmpclass->$key = $value;
}
$display_id[$key3] = $tmpclass;
}
}
}

A big thanks for starting on this, I don't have any Views API experience myself. I'll look into how well this works, along with other tweaks we might need to put in, and roll a patch.

I forgot about making a patch for this - it's direct from the code above, formatted properly. Please test & report results, so it can be added to the download.

Here is a tested patch for 5.x. I'm looking into 6.x + Views2 to see what needs to be done there. Could someone please confirm that it's working for 5.x, and I'll commit? Not sure if search is possible, but let's see if we can knock out one of the two now.

Not quite...

It works if the field is set to Nobody, but if the field is set to Buddies, it fails to check for that and instead shows the field data (ie NOT hidden).
Half a fix isn't quite a fix. Users who think data is only viewable by Buddies will be upset if it's actually viewable by anyone, including anonymous users.

Fix to check for buddy permission.

          $cckfp_sql = "SELECT cckfp.uid FROM {cckfp} LEFT JOIN {node} on {cckfp}.uid={node}.uid WHERE {cckfp}.uid <> %d AND {node}.nid = %d AND {cckfp}.field_name = '%s' AND
             ( {cckfp}.permission='n' OR 
                ( {cckfp}.permission='b' AND NOT( 
                   SELECT COUNT({buddylist}.buddy) FROM {buddylist} LEFT JOIN {node} as n2 on {buddylist}.uid=n2.uid WHERE n2.nid = %d AND {buddylist}.buddy = %d)
                ) 
          )";
          if (db_num_rows(db_query($cckfp_sql, $user->uid, $display_id[$key3]->nid, $termvalue2, $display_id[$key3]->nid, $user->uid)) != 0) {
            $value = "";
          }

This adds a check, within the SQL (which keeps it fast, and avoids two separate SQL calls) for the permission is 'b' but the person is NOT a buddy of the node author.
It might be possible to craft this as a single query with another join, but then you might to deal with NULLs from the join. The COUNT is required to avoid dealing with NULLs in the subquery.

@sethcohn Thanks for picking up on that. While working on trying to get Views2 integration yesterday, I noticed that only 'n' was checked for, but hadn't come back to this to redo the patch yet. I will test & reroll tomorrow.

Thanks to Andy (chaps2) - there is a patch to work with Views2 - it is confirmed to work with PHP5, but PHP4 is a question mark. If a few people could test out & review the patch for D6, I will be able to enter it into CVS.

Thanks,
Bryan O'Shea
Obsidian Design

This patch to cck_field_privacy.module is needed IN ADDITION to the patch I posted in #21 - there's three additional functions that are needed that I didn't include at first.

Rerolled as a single patch, some minor line cleanup. Works with the #350899: Padlocks not displaying in fieldgroups and #427022: hook form_alter rewrite patches.

Bryan

Committed to CVS, will show up in the next development release. Please test out the new version to make sure there aren't any issues that come up before I make a new release.

Bryan O'Shea

Is this patch included in the latest dev for d6/view2 ? I am using the latest dev, but views show up the fields, which are set to be seen by buddies. Using user-relationships (yeah i know, but i createt a rel-type buddy and its running on the nodes), Views2

Views support does seem to be broken. Marking #521710: restriction of fields to friends broken in views a duplicate of this issue to consolidate the discussion.

The patch in #1 of #521710: restriction of fields to friends broken in views also does not correct the issue currently, I'm looking into the issue.

Latest -dev doesn't work into Views2 when single fields are selected to build an output.

They're always visible, despite visibility rules that are set up.

is this issue still progressing?

any updates?

This is a dead project friend, try 'CCK Private Fields'. Thats what im now using.