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

merlinofchaos’s picture

The 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.

dawehner’s picture

So is this a won't fix?

Alternative it could be configurable.

joachim’s picture

Yup -- 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.

dawehner’s picture

The problem is that profile fields uses different handlers for different data.

joachim’s picture

Make a new common class for them all to inherit from.

joachim’s picture

... ugh, except loads and loads of fields for Profile module use core Views handlers.

dawehner’s picture

That's what i meant.

joachim’s picture

Yeah, sorry. On holiday and didn't have access to the code.

How do we handle CCK fields that have field permissions?

dawehner’s picture

Sorry 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.

joachim’s picture

So 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.

dawehner’s picture

There is already a access callback and access arguments on views_data but it does not help because it's not configurable

Letharion’s picture

Assigned: Unassigned » dawehner
Priority: Critical » Normal

I 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. :)

dawehner’s picture

Assigned: dawehner » Unassigned
Category: bug » task

This is more like a task.

joachim’s picture

The reason this was a bug and critical is that it can result in sensitive data being exposed...

dawehner’s picture

You run into many more serious problems if you run the profile module ;)

joachim’s picture

Well, not security problems... it's a bit crusty but it's not evil.

seaneffel’s picture

I 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

MustangGB’s picture

Issue summary: View changes
Status: Active » Closed (won't fix)