profile listing carries over people's data on subsequent users

fixed (patch attached)

Since this is such an obvious problem, the patch is so small (1 line), and the effects are localized, I'm going to say it's ready to commit, but please disagree with me if this isn't the right fix.

It was happening on: http://treehouse.ofb.net/go/en/profile
which you can look at for background.

What would happen in the userlist was something like this:

Dries

Dries Buytaert
http://www.buytaert.net/
Java, virtual machines, profiling and instrumentation, embedded systems, online communities, self-organization, politics, usability, photography, gadgets, skiing, sailing, mounties, the future

chx

Károly Négyesi
http://www.buytaert.net/
Java, virtual machines, profiling and instrumentation, embedded systems, online communities, self-organization, politics, usability, photography, gadgets, skiing, sailing, mounties, the future

someotheruser

http://www.buytaert.net/
women, beer, music

newuser

http://www.buytaert.net/
women, beer, music

spamuser

http://www.casino.website/
women, beer, music

The site was upgraded from 4.6.3 (somewhat patched up to fix issues that apparently aren't going to get committed into 4.6 branch) to CVS 2005-11-25 sometime +08:00. I used the update.php script that came with the CVS version to run all updates from update_129 to update_154. I had installed profile.module on 4.6.3 before the update, and most users had created their profiles before the update as well.

all my field ids are smaller than 15, so this bizarre check isn't the one that's failing (but that should probably get fixed too)

  if ($field->fid == 18 || $field->fid == 19 || $field->fid == 20) {

I haven't tested this theory yet, but from a peephole inspection of profile_view_field(), I'm guessing that the $user object that gets passed in does not have object fields set for profile values which are blank. That would cause this branch

if ($value = $user->{$field->name}) {

to be if (UNSET), which would fail, and the function would fall off the end.

Anyway the patch with unset instead of assignment to NULL is attached.

How can we reproduce this?

To answer this question, I think this might work:

• start with install of drupal cvs head
• create some profile fields that display in the user list.
• create some users, but don't log them in ever, so that most of the users don't have any of those profile fields set to anything
• create one user and put stuff in their profile
• log in the populated profile user so that they move to the top of the user list
• go look at url('profile')

That's fine too.

That was the first approach I took, but thought that a smaller patch might be more likely to be accepted.

Patch attached implementing comment #7

it looks like this bug report had morphed to mean something else.

re-marking as fixed, since the problem originally reported in this bug report was indeed fixed, independent of whether or not it recurred later.