We use Views 2 to create an automated address book of all our site members. Members, however, must be able to specify what private information they want to appear in the address book - and we want to use Profile Privacy for that.
When using Views 2 to create the address book - ie. a lists of users - Views seems to be unable to see the privacy settings for different fields, as set by Profile Privacy - which is a great, great pity.
Would there be any way for Profile Privacy to work with Views - or for Views to be aware of the field settings of Profile Privacy?
Many thanks in advance for your fantastic work - it's very much appreciated.
Comment | File | Size | Author |
---|---|---|---|
#33 | profile_privacy_patch19.zip | 208.31 KB | seaneffel |
#31 | profile_privacy.zip | 17.31 KB | M_Z |
#30 | picture3.png | 127.88 KB | seaneffel |
#30 | picture4.png | 189.72 KB | seaneffel |
#30 | picture5.png | 122.82 KB | seaneffel |
Comments
Comment #1
icouto CreditAttribution: icouto commentedPlease note, that I've posted this request in the Profile Privacy queue, rather than in the Views queue, because of the following warning that appears when we try to create a new ticket in Views:
Once again, many thanks in advance for any and all help! :-)
Comment #2
quicksketchThanks, this is definitely a better place to post. Great job reading guidelines! Merlinofchaos would be proud :)
Regarding the issue, this should technically be possible with Privacy Profile, however I'm barely maintaining the module, so it's likely that any additions will need to be provided through a patch (which I'd be glad to apply). Unfortunately I don't have the time to invest in this particular problem.
Comment #3
gausarts CreditAttribution: gausarts commentedsubscribing, thanks
Comment #4
milos1234 CreditAttribution: milos1234 commentedsubscribe.... big time
Comment #5
finfin82 CreditAttribution: finfin82 commentedHi,
i solved this problem by adding the following views_query_alter hook to profile privacy.i allready extended my profile privacy to work with user relationships so it could be, that you have to fit the PROFILE_PRIVACY_BUDDIES <-- etc defines to your needs
maybe this could be useful for somebody,
cheers finfin
btw: the user_relationship implementation will be commited as well, if i find the time to tidy up my code ;-)
this will see the first views arg as user-id ... mayb this information is better grabbed form anywhere else
i guess there is an error in reasoning in this case :-) the $view->args[0] should be the userid of the actual resulted user.... so forget about this solution ;-(
may be this will push someone in the right direction
Comment #6
finfin82 CreditAttribution: finfin82 commentedI tried to solve the problem with another approach.
I tried to use the preprocess_views_view_field function
but although i unset or empty the content of $vars['row']->$field2hide it's shown in the view-result on page,
so how do i unset a fields content, that it's no longer shown in result.
maybe merlinofcaos can help here?
cheers finfin
Comment #7
kentr CreditAttribution: kentr commentedI know little about views, so please forgive my ignorance.
Could this be better solved with a profile "relationship" for views that automatically detects the privacy of an individual field and hides it at the query level?
Comment #8
ardi1983 CreditAttribution: ardi1983 commentedI found a solution to this problem in the template that views supplies , using a function of profile_privacy module that return 1 in case of private and 0 in case of public field, the function is: profile_privacy_get_user_field_privacy($uid, $field_name), i take the user from the url... hope I can help someone :D :D :D
Comment #9
kentr CreditAttribution: kentr commentedI'm pretty close to getting a patch for this.
Comment #10
kentr CreditAttribution: kentr commentedHere's a beta patch. I got confused with Profile Privacy's access restrictions, so I ended up starting from scratch on the access specs.
This patch could be a separate module if necessary. Please indicate whether this is likely to be added to Profile Privacy, and if not I'll post it as a separate module.
Access specifications:
(Profile module's specification: "content shown on profile page and on member list pages.")
(Profile module's specification: "content shown on profile page but not used on member list pages.")
(Profile module's specification: "content only available to privileged users.")
This means that for the purposes of Views, PROFILE_PUBLIC and PROFILE_PRIVATE are treated the same.
(Profile module's specification: "only accessible by administrators, modules and themes.")
This behavior can be overridden as described below.
Additional features:
Users cannot further override this setting because they cannot set Profile Privacy options on these fields on the Profile edit page. In the event that the field was formerly a status other than PROFILE_HIDDEN, there may be residual per-user Profile Privacy settings for the field. If so, those settings are ignored.
This feature is useful for Profile fields that you want displayed but kept non-editable by the users.
Known issues:
Comment #11
coltraneThis is great, I haven't reviewed yet but hope to soon. I've been neglecting this module :(
Comment #12
acPatch is working well for me so far. Will report any issues I find.
Comment #13
acSo far this is working perfectly. Anyone else tested? Too premature to mark RTBC?
The only issue that I have (which was listed as known by the author) is "The wrapper markup for private fields appears even if "Hide if empty" is set for the field. I consider this a high priority for bandwith and theming reasons."
I assume this is because "Private fields are wrapped with " but I may be wrong.
Comment #14
kentr CreditAttribution: kentr commentedYes. I've been unable to dig into the views system enough to find a better solution. Feel free to patch the patch ;-).
The code you're looking for is in the
render()
methods of each of the custom views handlers. It could be as simple as adding an "if not empty..." condition.Ideally, the HTML would be moved to a theme function or template. Just haven't figured that part out yet.
But I also request that we don't let that be an obstacle to getting the patch committed.
Comment #15
coltraneRight on, patch applies and works great. The wrapping HTML won't keep this patch from getting in. Thank you kentr for writing this and ac et al for testing.
I noticed some issues with replacement user-supplied text that should be handled. It's all the handlers like below.
If you want to allow for translating, that's fine, but this does not escape the replacement text. Use check_plain() or variable substitution (@text) instead. Unless there's a Views-specific way to handle this.
And here. Also, what's with the ending 'x'?
@kentr, are you implying someone could POST to the Views edit form with the value set for overriding hidden field display? FAPI protects against most form semantic hacks and I believe it would in this case if the form element wasn't in the FAPI build array the POST processing won't accept it.
Comment #16
kentr CreditAttribution: kentr commentedWhen you say 'escaped', do you mean stripped of HTML? Does it need to be? I was assuming that whoever is editing the view will have high-enough privileges that they're not a XSS risk, and HTML might be desired in the replacement text, but if you want it stripped, that's OK with me.
After further reviewing
t()
, I think that part is unnecessary. I incorrectly thoughtt()
was the general language translation function.Oversight. Will remove.
Yes, that was my concern. Glad to know that it's probably not an issue.
Comment #17
coltraneI meant escaped but HTML stripping would work as well. Someone with the permission to administer views may not have other administration permissions and they could place script code in the replacement text that could allow them to gain higher permissions on the site. HTML is ok in the replacement text, but we should use filter_xss() or filter_xss_admin() then so script tags aren't allowed.
Comment #18
kentr CreditAttribution: kentr commentedIt may be a while before I can make these changes, so if someone else is able to, please do so.
Let us know, so we don't duplicate efforts.
Comment #19
M_Z CreditAttribution: M_Z commented@coltrane and kentr:
I attached a modified patch:
- removed the "x" in one of the 7 Views field handlers
- in all 7 Views field handlers: replaced t(...) by filter_xss_admin(...) - translation of the replace text is handled by Views (because 'translatable' => TRUE is set in options definitions - I tested translation behaviour with my multilanguage Drupal installation and everything works fine)
- in all 7 Views field handlers: replaced else { by elseif (drupal_strlen($this->options['profile_privacy_replacement_text'])) { to skip
<span>...</span>
output for empty replacement textI also tested the "old" patch and it worked very well - but I am not sure, if I should change status to RTBC after modifying the patch.
By the way: I had some problems in applying the patch - I had to move the profile_privacy.views.inc and the complete handlers directory in a manually created "views" directory.
Looking forward to see this patch in next release!
Greets,
Martin
Comment #20
seaneffel CreditAttribution: seaneffel commentedPing. Hoping there was some movement on this. I have an interesting use case for this module in Drupal 6. Let me know how I can help.
Comment #21
bryancasler CreditAttribution: bryancasler commentedsubscribe
Comment #22
M_Z CreditAttribution: M_Z commented@seaneffel:
Because you are asking "Let me know how I can help."...
Have you tried my #19 patch? Changing the issue status without reporting, if the patch works fine for you is a little bit strange.
@animelion:
Instead of subscribing it would be nice if you could tell us if you tried my #19 patch. Thanks in advance.
Comment #23
bryancasler CreditAttribution: bryancasler commentedI have not, I subscribed to remind myself to try this module later when I have time
Comment #24
seaneffel CreditAttribution: seaneffel commentedProbably the change in status was a fat finger error.
I've applied the patch in #10 and #19 and I get no results. From what I can gather in the whole thread, its just a patch that will allow Views to respect the privacy settings of the Profile fields, and neither of these patches do that for me. I've got a fresh installation of Views 6.x-2.12 and Profile Policy 6.x-1.2 on Drupal 6.20, and built a nice straightforward view. See this screenshot:
http://drupal.org/files/issues/screenshot1_0_35.png
In the screenshot you can see that none of the profile fields are marked as public, and you can see that while the profile page hides the fields, Views does not.
http://drupal.org/files/issues/screenshot2_0_35.png
Could this be that incremental changes to Views over the last eight months has broken the patches you submitted?
Comment #25
seaneffel CreditAttribution: seaneffel commentedSorry... stupid file names.
Comment #26
seaneffel CreditAttribution: seaneffel commentedCross referencing this other issue that deals with Views and privacy of Profiles, just in case it's pertinent:
http://drupal.org/node/816992
Comment #27
M_Z CreditAttribution: M_Z commented@seaneffel:
Please try to view your view with a user different from your superuser 1!
(To be more precise: By design of the views field handlers user_access('administer users') leads to show all profile fields without regarding profile privacy settings.)
If it doen't work please post a screenshot of a profile field (in edit mode) and a screenshot with field settings in Views for one profile field.
I can say again, that my patch #19 works fine for me.
Comment #28
seaneffel CreditAttribution: seaneffel commentedSure, I'll try again with another user that is not uid 1. But I don't think that is the issue. The view pulls profile fields from user 1 but the it displays them to anonymous user session. That's in the screenshot.
I would think that when user 1 hides profile fields then anonymous users shouldn't be able to see the fields. Am I right?
I'll be back with more screenies later today.
Comment #29
seaneffel CreditAttribution: seaneffel commentedConfirming that patch #19 is not delivering for me. Check the screenshots, they are pretty straight forward.
Shot #3: Shows the privacy config of one of the fields, the High School field. It is a private field that allows users to override the privacy settings. That appears to be configured correctly. I got the same results when the field was set to a default of public, too.
Shot #4: Shows how uid 3 configured his High School field as not public but the College field is public. The top right shows how the anonymous session cannot see the High School field of uid 3 when looking at the profile page. However, the bottom right shows how the same anonymous session can see all fields when the fields are presented through a view.
Shot #5: Just for diligence, here is a screenie of the view from shot #4 so you can see how it was configured.
All in all, I can report that the patch in #19 is not working for me unless there is some missing step that I have missed. Could there be more steps I've missed in configuring the view?
Comment #30
seaneffel CreditAttribution: seaneffel commentedFreaking attachments is not working on d.o. Here they are again...
Comment #31
M_Z CreditAttribution: M_Z commentedThanks for your answer.
1. Could you post screenshots where we can see the configuration of your 2 profile fields from screenshot no. 5 (picture5.png).
2. I try to add a zipped version of my current profile_privacy directory, so you could try to diff my folder with yours to report any differences here.
Comment #32
seaneffel CreditAttribution: seaneffel commented1. I'm sure my fields are configured properly in my example, and I posted the config of my one profile field in screenshot 3 above. But...
2. Your zipped module works for me. After applying this patch, my file structure doesn't match yours. All the new .inc handler files that the patch generated did not get filed into the privacy_policy/views/handlers directory but when manually moving the files into the right place I get the behavior I need. Your zipped files is also missing the screenshots directory from the original module. The short is, it wasn't as simple as applying the patch.
I'm no whiz at making patches but if this patch could structure the files correctly then it would be ready to roll.
Comment #33
seaneffel CreditAttribution: seaneffel commentedJust for reference, this is what my module looks like after applying your #19 patch. No deeper directories. Screenshot directory is present, too.
Comment #34
M_Z CreditAttribution: M_Z commented@seaneffel:
As I wrote in #19 I had some problems in appying #10 patch (and I thought the reason could be using git instead of cvs).
I modified my improvements directly in the old patch.
Because moving files to the right place (like described by seaneffel in #18) should be an easy task for the maintainer of this module, I suggest that #19 solves this issue and seaneffel should change status to rtbc and assign the issue to coltrane (the maintainer).
By the way: I removed the screenshots directory because in my opinion these files shouldn't exist there, because they aren't used in the module. (at least up to now - see http://drupal.org/node/751656)
Comment #35
seaneffel CreditAttribution: seaneffel commentedOk then.
Patch 19 works fine after moving the resulting files to the right directories. Maintainer can decide on what to do with the screenshots. Consider this RTBC.
I am unable to change the assignment but I'm hoping coltrane can commit this so I can put the patched module to use right away.
Comment #36
MacaroniDuck CreditAttribution: MacaroniDuck commentedsubscribe
Comment #37
cor3huis CreditAttribution: cor3huis commentedComment #38
cor3huis CreditAttribution: cor3huis commentedAs far as I can see the improvements all work. A 6.x v1.x Dev release with all this patches merged and included would be very welcomed. Work toward a stable 1.3 could commence and then the improvements ported to the D7 Dev version.
Comment #39
cpliakas CreditAttribution: cpliakas commentedI repurposed this patch and committed at #1268114: Views integration. The original patch worked well, although it did cause some performance issues. Added some static caching to the downstream project in order to reduce the amount of access checks performed by the _profile_privacy_views_field_access() function.
Comment #40
cpliakas CreditAttribution: cpliakas commentedMoving to the 6.x-2.x branch. Committed at 21f7146.