This is an add-on submodule to user_relationship. The idea is to allow site admins and individual users hide certain profile fields from those who are not in a relationship with them. Profile fields are not from the core profile.module but CCK nodes from content_profile.
This module is still a work in progress but implements most of this functionality. Would like someone trying it out and posting feedback on UI and features.
When creating/editing nodes designated as profile nodes, the module inserts controls for each field, to make the field private (i.e. not show to anyone but site admins), show to one or more relationship types (checkboxes), or keep it public to everyone.
Admins can set default visibility (to certain relationship types, or private) when configuring the CCK type. In that case the user cannot override their individual profile fields that were pre-set by admin.
Privacy works when looking at someone's profile, and when using search (core search) out of the box. It also works with Views, with a little tweaking.
- For views shown as a table, no changes are needed.
- For other display types (List, Unformatted) that use a Row Style, there is a row style plugin provided by the module called 'Profile Fields'. It applies privacy controls as the view is rendered. This is set in the Basic settings area of the view.
If the profile node is being shown on the registration form (http://drupal.org/node/260578, currently in a dev release of content_profile), privacy controls are not shown to keep it simple. This can be overridden with a config variable: add this to your settings.php $conf['user_relationships_field_perms_alter_registration_form'] = TRUE;
Outstanding issues:
- Viewsthat use grouping: when grouping on a field that is subject to privacy controls, the node will still appear among other nodes grouped, even though its value is hidden. That's pretty serious, working to fix that.
- Searching may bring up nodes where matching keywords are hidden, but displaying search results will not expose them.
Anyone using content_profile, it'd be great to test it on someone else's site.
Comment | File | Size | Author |
---|---|---|---|
#32 | view-field-permissions.txt | 2.6 KB | Jehu |
#27 | user_relationship_field_perms.zip | 27.86 KB | sumitk |
#20 | content_profile_view.gif | 19.37 KB | prdsp |
#8 | user_relationship_field_perms-20090503.tar_.gz | 8.23 KB | alex.k |
user_relationship_field_perms.zip | 18.67 KB | alex.k |
Comments
Comment #1
miraclestyle CreditAttribution: miraclestyle commentedIt seams that this module isn't working on beta9 version of User Relationships!
Elaboration:
After changing the visibility of a Content Profile node field (and saving the node), no matter of what options have been chosen, the field visibility setting defaults to "Show this field to: All Users", and the field remains visible indeed, to all users!
P.S. Apologies for any mistakes in Issue Settings, this is my first bug report. :D
Comment #2
alex.k CreditAttribution: alex.k commentedPlease wait a bit, there is a much updated version of this module that I'm finishing up, I will commit it for the next release if it passes testing.
Comment #3
advseb CreditAttribution: advseb commentedsubscribe
Comment #4
Liliplanet CreditAttribution: Liliplanet commentedsuper subscribe! thank you!
Comment #5
SocialNicheGuru CreditAttribution: SocialNicheGuru commentedi will help test this. is there an official page for it?
how does this work with content privacy (the new cck field privacy)? Is it an either or relationship?
Chris
Comment #6
design.er CreditAttribution: design.er commentedAlex, thanks a lot for this great feature! :)
I have the same bug as described in #1 and need this module for my current project, so I will help with testing and hope we'll get ready in/on time. ;)
Best Regards,
Stefan
Comment #7
SocialNicheGuru CreditAttribution: SocialNicheGuru commentedhow is this different from this module with this post
Integration of CCK_field_privacy with user_relationship_module
http://drupal.org/node/377950
Comment #8
alex.k CreditAttribution: alex.k commentedCCK Field Privacy provides privacy when viewing profile nodes. This module also provides privacy when using Views to display profiles, as well as when profiles are searched. The situation with CCK Field Privacy may have changed in the last few months, not sure.
I almost committed this module to UR for beta10 release, but it turns out it only supports views of type Node. If you build a view of type User or User Relationships (and use a relationship to pull in profile fields) privacy will not work. I'm attaching that version, which supersedes what was posted previously. With that caveat, it should work otherwise.
Comment #9
alex.k CreditAttribution: alex.k commentedComment #10
prdsp CreditAttribution: prdsp commentedThis works well on regular core user profile pages with content profile enabled, however, when you apply the patch to content profile discussed here http://drupal.org/node/430220 which allows you to pull cck fields from content profile into panels 3, the fields that are supposed to be hidden are still visible. Is there any chance you might integrate this module with panels 3 and the patched version of content profile as this seems like its going to be the wave of the future when it comes to creating custom user profiles?
Comment #11
alex.k CreditAttribution: alex.k commentedSounds interesting. However, I have never written for Panels, and don't use them currently. Anything it does differently than node_view would have to be accounted for.
Comment #12
prdsp CreditAttribution: prdsp commentedPerhaps Merlin, Michelle and Fago could provide you with the assistance you need on this. If these 3 modules could work together it would be very powerful. I'm not a coder but I'm familiar with using all three modules and can provide assistance with testing.
Comment #13
prdsp CreditAttribution: prdsp commentedI've added a new feature request in the Panels 3 issue queue to have this module integrated with Panels. You can find the thread here http://drupal.org/node/466956
Comment #14
alex.k CreditAttribution: alex.k commentedThanks, appreciate you following up.
Comment #15
Michelle@alex: I don't know when I'll have time to look at this. If it helps to figure out why your code doesn't work with the CCK/Panels integration, here is the code that displays a field:
And this is to display an entire fieldgroup:
Michelle
Comment #16
alex.k CreditAttribution: alex.k commentedThanks, Michelle. I wonder if Panels works with content_permissions module. It implements the same kind of security, i.e. adding the #access flag during hook_nodeapi(op = 'view'). I modeled this module to the same behavior. If the view op is never called, then I think no access control modules would have a chance to mark up the fields.
Comment #17
Michelle@alex: I haven't had a chance to dig into it but I think the key thing here may be that Panels isn't displaying the node; it's displaying the fields (or fieldgroups) directly.
Michelle
Comment #18
alex.k CreditAttribution: alex.k commentedYup it's in general something that is easy to overlook when working with nodes... it's tempting to pull out fields knowing that the node as a whole is accessible - but if any modules try to apply access controls at the field level, the best practices are not so clear.
Comment #19
MichelleNot a matter of being "tempting"; it's essential. It's the basis of the integration to be able to add individual fields and fieldgroups wherever you want on a panel. Overall node access can be taken care of at the context level but modules addressing things on the field level can't rely on those fields always being associated with the node. This will be even more important in D7 when fields can be added to anything.
Michelle
Comment #20
prdsp CreditAttribution: prdsp commentedI tried creating a content profile field view of type node and adding the view to the panel as a work around, however that didn't work either. I was thinking that since the view was of type node it might work but it doesn't
Comment #21
Michelle@alex: I gave this some more thought while I was taking my son to school. Panels isn't the only issue here. Content Profile also provides the ability to display the fields anywhere. Any privacy module that relies on the fields being on the node in the normal manner isn't going to do it. It needs to be done at the field level. CCK already provides field viewing security but that's for the admin to set per role. It could serve as a model, though. If CCK doesn't provide the hooks needed to provide privacy directly, I suggest a patch to CCK do add in a hook for that. Then any module displaying CCK fields / fieldgroups would do it using the API that triggers hooks for other modules to deny access.
My apologies if any of this has been discussed. I was directed over here from the CP relationship issue and haven't been involved in this whole issue.
Michelle
Comment #22
alex.k CreditAttribution: alex.k commented@prdsp in the view, use the "Profile fields" row style - this lets ur_field_perms do its work because the view is not a table view.
Comment #23
prdsp CreditAttribution: prdsp commentedChanging the row style didn't seem to have any effect. I am however able to get the entire content profile into panels with the UR field perms being fully functional.
This is done by adding a profile node relationship in the context tab...then when you go to add content to a region a new category will show up called node which should be right below miscellaneous...after clicking on the node category select node content...when the settings page appears uncheck "no extras" to make sure that your cck fields show up.
The only drawback to this is that you can't just only show certain fields...you have to show all of the content profile node. But the user is able to hide whatever fields they don't want to be seen. With the exception of the non-cck title, body & comment fields as it appears that the UR field perms module does not provide settings to hide the non-cck fields.
But the user does have the option to leave the body field blank & leave the comment field disabled. Or the administrator can get rid of the title by checking the override the title in the content settings when adding the content pane to a region in panels and leaving the override title blank. The administrator can also disable the body field when editting the content type by leaving the title of the body field blank...the admin can also leave comment disabled there as well. Doing all of this would leave you with just the cck fields which the user can hide or show as they please.
I am wondering though if it would be possible to add the views that are of type node to the new node category that appears when you add the profile node relationship in the context tab. Maybe having the views that I created above classified under the node category in panels instead of the views category would allow the ur field perms to work? I guess thats an answer that Michelle or Merlin would know more about.
Comment #24
dbeall CreditAttribution: dbeall commentedsame issue w/profile fields in APK, but after getting it in I don't want to give it up.. it's a little over my head. interesting discussion, keeping an eye on this one..
Comment #25
alex.k CreditAttribution: alex.k commentedFWIW part of the reason this module doesn't offer options to hide non-CCK fields is I did not have any need to do that... The reason why is that it's possible to stick just to CCK for most if not all data in a user profile, unless you're doing something unusual. Consider:
* Title can, and should, be hidden using auto_nodetitle module, I set it automatically to be user's first and last name
* Node body - as you mentioned, it's hidden using standard node type options.
* Taxonomy - if you need to use this, use content_taxonomy, as it allows to tag nodes without saving the tags into the taxonomy system.
* Not sure there is anything else that comes to mind...
In any case, if the panel is showing a complete profile node then usual CCK "Display Fields" settings in content type setup should apply, i would think.
Comment #26
MichelleIt should, yes. The problem is that you generally won't want the panel to show the complete node but rather display fields and fieldgroups individually for better placement. And that's where depending on the whole node being there falls down.
Michelle
Comment #27
sumitk CreditAttribution: sumitk commentedAbove module is not checking if a user has approved friend request of other user or not .. instead it is directly showing all profile fields checking rtids .... which is wrong as it should also check approved column of relationships table (set to 1 in approved case).
You can correct this by replacing this function in user_relationship_field.perms.module from line 356
Modified module is in attachment.
Comment #28
sumitk CreditAttribution: sumitk commentedAbove code is fetching approved variable in $approved array as
and testing a condition if it is 1 OR not.
Comment #29
chaosprinz CreditAttribution: chaosprinz commentedHello,
i dont know if it can help ya guy with your real cool work. I enabled the submodule from #29 and got these 2 messages directly after turning on the module:
Let me me know if you need more infomation and what kind of information.
Comment #30
SocialNicheGuru CreditAttribution: SocialNicheGuru commentedcan 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.
I have read this thread and the one I posted and I would love your advise on which solution.
thanks,
Chris
Comment #31
yajnin CreditAttribution: yajnin commentedsubscribe
Comment #32
Jehu CreditAttribution: Jehu commentedIn my view the contents are always shown no matter the field privacy settings. Please take look at the view i've attached.
Comment #33
okday CreditAttribution: okday commentedWhy not including this sub-module in the user relationship suite?
Comment #34
okday CreditAttribution: okday commentedMy hidden fields are always shoen too.
Please update this module.
Comment #35
brunorios1 CreditAttribution: brunorios1 commentedsubscribing...
Comment #36
mrf CreditAttribution: mrf commentedComment #37
mrf CreditAttribution: mrf commentedDon't see this getting added to 6.xt, and this would end up being a very different module for 7.x.
That being said I think its a very useful, and it would be great if someone takes what is here and fixes the remaining bugs.