Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Users' access to fields from Profile module is not checked.
This should probably be done with access() in a new handler that takes care of all profile fields, which the current profile fields can inherit from.
Comments
Comment #1
merlinofchaos CreditAttribution: merlinofchaos commentedThe problem is that if you do that, the fields become always invisible, all the time. That makes it impossible for the administrator to set up a field that's excluded from the normal profile page, yet visible in a view.
Comment #2
dawehnerSo is this a won't fix?
Alternative it could be configurable.
Comment #3
joachim CreditAttribution: joachim commentedYup -- we could add a handler to take care of all profile fields, with an option to either obey that field's privacy setting or not.
Comment #4
dawehnerThe problem is that profile fields uses different handlers for different data.
Comment #5
joachim CreditAttribution: joachim commentedMake a new common class for them all to inherit from.
Comment #6
joachim CreditAttribution: joachim commented... ugh, except loads and loads of fields for Profile module use core Views handlers.
Comment #7
dawehnerThat's what i meant.
Comment #8
joachim CreditAttribution: joachim commentedYeah, sorry. On holiday and didn't have access to the code.
How do we handle CCK fields that have field permissions?
Comment #9
dawehnerSorry what's holiday, i don't understand this word.
Beside that fact that there is afaik no access check cck implements nearly each handler: argument/filter/sort/relationship for the basic data types again.
Comment #10
joachim CreditAttribution: joachim commentedSo it does.
But content_handler_field has nothing about access at all.
This suggests to me we should think about something like an access callback property on field definitions.
Comment #11
dawehnerThere is already a access callback and access arguments on views_data but it does not help because it's not configurable
Comment #12
Letharion CreditAttribution: Letharion commentedI can't determine what needs to be done, but it doesn't sound "critical", so I'm demoting that, and assigning it to dereine, since he seems to be involved the most. :)
Comment #13
dawehnerThis is more like a task.
Comment #14
joachim CreditAttribution: joachim commentedThe reason this was a bug and critical is that it can result in sensitive data being exposed...
Comment #15
dawehnerYou run into many more serious problems if you run the profile module ;)
Comment #16
joachim CreditAttribution: joachim commentedWell, not security problems... it's a bit crusty but it's not evil.
Comment #17
seaneffel CreditAttribution: seaneffel commentedI bet if this issue were resolved in a way that Views respected the privacy settings of profile fields, then this other issue would come closer to being resolved as well:
http://drupal.org/node/311301
Comment #18
MustangGB CreditAttribution: MustangGB commented