Integration of CCK_field_privacy with user_relationship_module

Currently, the behavior you list is 'by design' - UR does not provide any roles for CCK Field Privacy to use. However, you can use one of the types as the 'buddies' category, and UR will match that to CCK Field Privacy's 'Buddy' status.

No current plan to incorporate UR roles, as I don't use UR, but if anyone would like to provide patches to do this, I will gladly include them.

Thanks,
Bryan O'Shea
Obsidian Design

How does UR match a user relationship to "Buddies" in the popup. Are there instructions?

If that is the case, is there an easy way to have more than one "Buddy" type and then I could manually (given the instructions from my question above) to match it to my UR relationships.

Thanks,
C

BTW- on the project page it says Friendlist and User Relationships are supported in D6. If that is not true, can the page be changed so that others like myself don't think that it is ready out of the box.

Thanks again!

hi,
i'm working on a patch for cck_field_privacy module integration with UR should have something in a day or 2 which i'll post to this thread.

posting patch for integration with User Relationship types -

- Have removed 'Buddies' type since there is no dependency on the buddylist module in the info file, so this wont work out of the box.
The two types of privacy by default are 'Everyone' and 'Nobody'

- If user relationship module is installed it will pick up all the types from that and display them as default options in the CCKFP settings page.

- Have also updated the DB Schema to allow for more than 1 char in the 'permissions' field, so you will need to run update.php after you apply this patch . This allows for many UR types to be stored in the db since it allows more than 1 letter.

one further thing is i have added an extra argument to the cck_field_privacy_access() hook which passes the permission type. This allows the UR module to check a relationship of this type exists between the users, instead of simply a relationship of any type.

This requires a patch to the UR module which i am happy to post also, for now i will add the code here, until you review and are happy with the patch, then i will post the patch to the UR issue queue.

In user_relationships_api.api.inc you need the following, to replace the hook cck_field_privacy_access function -

/**
 * Implements the hook_cck_field_privacy_access to allow users to display privacy fields
 * based on a relationship with other users
 */
function user_relationships_api_cck_field_privacy_access($requestee, $requester, $rel) {
  $relationship = user_relationships_load(array('between' => array($requestee->uid, $requester->uid), 'approved' => TRUE, 'plural_name' => $rel), array('count' => TRUE), FALSE);
  return $relationship;
}

thanks
Graham

re-attaching patch, forgot to remove a line of debug in the .js file.

How is this different from the UR relationship field permissions?

user_relationship_field_perms
http://drupal.org/node/304317

I am a little confused about which way to go. I am not sure if this is a duplicate?

activelyOUT - in theory, having UR work through this module simplifies the process. If a site has profiles + regular CCK content types that users can create (and want to hide fields), then just having the UR relationships module won't help, as in reading it, it only covers content profile types. Now, if content profile support is all a site needs, then using the UR module would be fine; this is an extension of the cck field privacy module that will allow it to expand & work with more relationship types for ALL CCK types.

tayzlor - unfortunately, some changes to the implementation of hook_form_alter and hook_nodeapi that took a higher precedence are going to make your patch fail once they are implemented. I was wondering if you'd be able to re-roll after those changes are committed, so that we don't lose the effort you put forth? I'm not sure how much of an undertaking it will be, but it was hard to implement all these different things at once, since they all changed a lot of the same things. Thanks for your help in getting things moved forward with this module. I'm marking it back as 'needs work', since it will. If you apply #350899: Padlocks not displaying in fieldgroups and #427022: hook form_alter rewrite and then check your patch, it may give an idea of what needs to be done.

HTH,
Bryan

just saw this, got some scheduled work to do on this, so will re-roll my patch against dev. i'm going to change my patch slightly so it takes a different approach which should work better, but still along the same lines. hope to have another patch ready in a day or 2.

Attaching a new patch file to cover this, patched against latest dev snapshot.

Comments in #4 still apply, you will need to run update.php and add that code to UR module if you want it to work with UR. As i said before, i will submit a seperate patch to the UR module if this one gets adopted.

cckfp now stores serialized data in the db for 'permission' instead of a single char. This allows it to stores multiple permissions per cck field, So you can for example allow you're 'friends' and 'colleagues' to see the field when integrated with UR.
I have also updated the JS from radio buttons to checkboxes to allow for this multiple permissions per fields.

havent tested views integration to see if it still works, but updated the code accordingly and hopefully it should work.

just double checked patch, seems to be a bug in it. will re-upload new patch tomorrow.

new patch, bugs fixed in .install file

And another.... added an extra check in nodeapi 'view' to check if you are on an Enabled Type, if not it doesnt perform the query.

Is it possible to add privacy for each relationships defined?

@4vinoth,
yes the patch provides the option of hiding / showing the cck field to all, nobody, or any combination of the user relationships defined by your UR module

I've installed the patch in #13...and I've updated the ur code in post #4...however, the jquery impromptu box no longer appears when I click on the padlock

I have the jquery impromptu library installed correctly and the box appeared prior to patching???

I'm running drupal 6.11

UR-latest dev released 7/6
cckfp latest dev released 6/11
cck 2.4
and content profile beta 4

In addition, I get an error in firebug that says that console is not defined in line 3 of cck_field_privacy.js

console.log('init called');

Code works for me (6.13 / UR beta 10 / cckpf -dev), though I had to manually apply the patch in #13 on the latest dev (some hunks failed)

Also applied the patch at #4 AND commented the line:

console.log('init called');

in cck_field_privacy.js which caused the popup to fail under firefox en ie (worked for chrome though)

Don't forget to set your permissions right afterwards.

askibinski - could you possibly please reroll the patch as one again, removing the console.log line? That would help others test the module with less effort.

Thanks in advance,
Bryan O'Shea
Obsidian Design

Right now, #320467: Any plan to integrate with Popups? is up for review. This patch and that one conflict in some ways. In the popups api patch, the form is now generated using proper forms API functions rather than javascript. At a glance, it doesn't seem like many modifications will have to be made to update the popups patch with this one aside from rewriting the form function.

Depending on which patch is committed first, the other will have to be partially rewritten.

Also, using serialized data shouldn't break views access if #514452: Add new argument $node to content_access() to enhance the context for hook_field_access() goes through and we can make a proper field_access() hook with the node data. Right now I'm using a hack to accomplish proper Panels integration, but this would solve that too.

@obsidiandesign #18

I'll try to make a new petch against the latest -dev. Which will probably be still dirty but it hopefully will make life easier for review.

btw: I also noticed some weird clicking behaviour in the checkboxes popup (under IE only). I'll try to check that out too.

subscribing
I will try the patch when the next reroll will be out. Realy cool work, guys.

@ askibinski commenting out that line worked for me

I noticed that the patch could use a couple of tweeks. For example when you select nobody all the other check boxes should automatically become unchecked and unavailable to be checked...And when you select anything other that everybody...then everybody should automatically become unchecked and unavailable to be checked...and when you check everybody...nobody should automatically become unchecked and unavailable to be checked. This could lead the user to accidentally have everybody and nobody checked at the same time etc

Here's the patch!

Use against latest dev. It works with user_relationship and also fixes the click behaviour in IE.
It modifies .module and .js. Please review and test. I didn't have more time to play around with it.

@prdsp I would prefer radio buttons (it actually were radio-buttons in earlier versions).

Also, two questions about this module:

1. How hard would it be to implement this access on a per node basis? Now, It applies for all nodes for that user with that specific cck field.

2. In case of an imagefield, even if the image itself is marked private (or friends), they show up in thumnail (imagecache) views. I think this is a views/drupal core access or maybe imagecache problem but would love to know more about it.

I think there should be a combination of 3 radio buttons...first would be everybody...the second nobody...or if you selected the third radio button it would enable a list of check boxes that you can choose your specific combination of relationships that you want to see the field.

@ askibinski are you saying that the .install file no longer needs to be modified like in the previous versions of the patch? Because I already patched the install file and ran update.php...do I need to reverse that?

@prdsp: I wouldn't worry too much about how the form works right now. Once this patch is committed I'm going to reroll my patch against it that converts the form to forms API and uses Popups in place of Impromptu. I'm using it right now and it's very cool. The form could be made to use AHAH to implement your ideas.

As for views/imagecache issues: The field_access hook in CCK now supplies the $node context (#514452: Add new argument $node to content_access() to enhance the context for hook_field_access()). I've successfully patched my working version of CCK Field Privacy to use hook_field_access(), and this completely eliminates the need for using any of the code in hook_nodeapi as well as anything in views.inc and has the side effect of enabling Panels 3 integration. And it's 4 lines of code. I'll be submitting a patch at some point to the issue queue here.

Basically, if hook_field_access is implemented in place of all other current measures, and imagecache continues to behave weirdly, then it's almost certainly not the fault of Field Privacy. I haven't tested this in my implementation yet.

@prdsp
Right, sorry forget about the .install change. You will need to add that line.

@cpyle
Sounds great, can't wait to see that patch.
I didn't like the impromptu from start. Popups seems more like the way to go in drupal.

can I have your advise.

I am unsure about which way to go

do i use cck field permissions + ur
http://drupal.org/node/377950

or ur field perms module.
http://drupal.org/node/304317

I have read this thread and the one I posted and I would love your advise on which solution.

thanks,
Chris

I've rerolled the patch from #23 because it wasn't patching -dev correctly. I made a few more changes (it seemed that the access check wasn't working correctly after I applied it, plus I did some code cleanup), so could someone please test it independently before I commit? I'd like to get this committed tomorrow (Saturday).

Thanks!
Bryan O'Shea

Patch applies fine, but..
The checkboxes brake when you translate the strings "everyone" and "nobody" for your language using the core string translation tool (at admin/build/translate/search)!

You can verify this by installing another language and translate these strings in that language to some words.

@askibinski - I redid the patch (with the .install changes) today and it made a world of difference. What do we do about the situation where the user unselects each checkbox & clicks 'ok'? Nothing happens in the database, it seems, so the last checked box stays the status. However, in the popup, the value is not set if the user reopens the padlock setting form.

I'm committing to -dev so that we can try and work on some of the other improvements, but will hold off on a release until we can come up with how to best deal with the situation of a user unchecking each box.

Thanks for the big help with this.

Bryan O'Shea
Obsidian Design

Yes, that's why I don't like the checkboxes - you can uncheck every option which shouldn't be possible.

That's why imo it should be radio-buttons - just as they where in earlier versions. That way you won't have that problem.

But when there are multiple user relationships, it is theoretically possible to want A and B, but not C, to be able to see the content, so checkboxes are useful (and inevitably, it will be requested anyway). Storing a NULL value shouldn't be a problem (but it's not getting sent to the AJAX handler), because then the defaults could take over. My bigger concern is opening the popup blank - any ideas on that one?

I gave it some thought, I think the best way would be the way it's done on Flickr, see the attachment.

This way you combine radio buttons for any of the two options which are required, and make checkboxes available for each role. What do you think?

That would be a perfect way to do it!

@askibinski - There's something in the .js file now that's causing an issue. When the user changes checkboxes, every checkbox on the page (not just the popup) is being unchecked. I'm no JS expert - how do we go about fixing that?

@obsidiandesign
I think it's in line 65:

$("input[@name!='"+$(this).attr('name')+"']").each(function(){

But I don't have time to look into it. I would replace the whole thing with a structure like in #33. This way you won't need that code anymore.

subscribing

I use cvs version with UR integration, but...
Does not work ... When I click on padlock I get the error:
Line: 23
Error: Object doesn't support this property or method

What's the problem?

Thank you for this great module!

eZar

The dev version is working fine for me, I was wondering how progress is going on the 'radio button/checkbox issue'?

I would need to be able to add more than one relationship type per field so I think combining radio buttons and check boxes would be the better option.

@adam_c dev is not working in my case. ??I get the padock with ur checkboxes but its not implementing when i set to only friends or nobody. Did you do some patching from the patches above or implemented dev directly?

is it somehow possible to use different default privacy values for different relationship types?
so that (by default) field 1 is only viewable by group 1, field 2 only by group 2?

and another question: when i click the lock in create content, it doesnt work correctly. it just sends me back to the top of the page and i cant change any privacy settings.

Does the new dev version have Integration of CCK_field_privacy with user_relationship_module. Does it pick up all the types from UR and display them as default options? Or do we need to apply a patch do this even in the latest dev version.