(In reply to comment #1)
> Hi all. What's the version of the Bugzilla we're using?
>
3.6.6
> Also, did you try a manual write into the database?
Yes. When I do that, Brent's name shows up properly until the next time Brent logs in.

(In reply to comment #2)
> 3.6.6
Ok. I looked at the source code.
> > Also, did you try a manual write into the database?
>
> Yes. When I do that, Brent's name shows up properly until the next time Brent
> logs in.
I ran through the login code and check for when it links to "unknown". Seems something else (not login code) is causing this problem.
A few more questions.
Which DB field did you update? Is it profiles.realname?
After Brent logs in, are those fields re-updated (reverted)? Which means you'll see the value "unknown" in the fields concerned? Between user.html.tmpl and User.pm, I'd say there definitely is a value "unknown" written directly into Brent's "profiles.realname" record.
Is "b.easton@exemail.com.au" in DB field logincookies.userid?
Are you using LDAP? Did you activate LDAP user sync operations? The operations are in bugzilla_ldapsync.rb and syncLDAP.pl . Does it have anything to do with this: https://bugzilla.mozilla.org/show_bug.cgi?id=201069
I've scanned all the codes (without debugging). Nowhere can I see any update to profiles.realname upon login. One possibility could be that someone else has Brent's password, and is constantly changing his realname to "unknown".
A few things I need you to do:
- Duplicate the tracker wholesale, codes and DB
- In the duplicate...
- delete everything except 1 bug
- delete all users except admin and Brent
- change any personal info you don't want me to see
- Send that duplicate to me.
Can you do that?

(In reply to comment #3)
>
> Which DB field did you update? Is it profiles.realname?
Yes, profile.realname.
> After Brent logs in, are those fields re-updated (reverted)? Which means you'll
> see the value "unknown" in the fields concerned? Between user.html.tmpl and
> User.pm, I'd say there definitely is a value "unknown" written directly into
> Brent's "profiles.realname" record.
Yes, it's reset to "unknown" after Brent logs in.
> Is "b.easton@exemail.com.au" in DB field logincookies.userid?
No. logincookies.userid is a numeric field storing the same data as profiles.userid. (Brent has userid == 2.)
> Are you using LDAP? Did you activate LDAP user sync operations? The operations
> are in bugzilla_ldapsync.rb and syncLDAP.pl .
Yes, we're using LDAP. I don't see why we would need to use either of those scripts. I thought I had Bugzilla set to automatically create accounts on login for users appearing in LDAP.
> Does it have anything to do with
> this: https://bugzilla.mozilla.org/show_bug.cgi?id=201069
I think this is unrelated. Brent has logged in many times before.
> I've scanned all the codes (without debugging). Nowhere can I see any update to
> profiles.realname upon login. One possibility could be that someone else has
> Brent's password, and is constantly changing his realname to "unknown".
I think this is unlikely. Brent and I were in the IRC channel testing this shortly before I added the bug. An attacker would have to have been monitoring the channel in order to reset Brent's account at the right times.
> A few things I need you to do:
> - Duplicate the tracker wholesale, codes and DB
> - In the duplicate...
> - delete everything except 1 bug
> - delete all users except admin and Brent
> - change any personal info you don't want me to see
> - Send that duplicate to me.
>
> Can you do that?
I won't be able to do this until tomorrow at the earliest.

(In reply to comment #6)
> Which files would you like me to checksum?
Possibly the whole of 3.6.6 build? Try http://sourceforge.net/projects/fsumfe/
Actually, the first thing to check is that no files were changed. Just do a recursive md5sum will do, actually.

(In reply to comment #3)
>
> A few things I need you to do:
> - Duplicate the tracker wholesale, codes and DB
> - In the duplicate...
> - delete everything except 1 bug
> - delete all users except admin and Brent
> - change any personal info you don't want me to see
> - Send that duplicate to me.
>
> Can you do that?
You just want a copy of the code and DB, not a working instance on another VM?

(In reply to comment #10)
Wait! Don't bother with duplicating your website yet. Sorry for my haphazard diagnoses.
Just a quick hopeful potshot here...
In Brent's LDAP account: username is what? displayName is what? cn is what?
Take a look at Bugzilla::Auth::Verify->create_or_update_user(), line 121:
if ($real_name && $user->name ne $real_name) {
(Logic goes like this. If LDAP's displayName or cn is not empty, AND Bugzilla's profiles.realname is not empty, then compare Bugzilla's profiles.realname with LDAP's displayName or cn. Compare with displayName if it is not empty, else compare with cn.)
Note that LDAP's displayName (or cn) always overwrites Bugzilla's profiles.realname.
And other potshots, just in case...
Did Brent logout first before you database-corrected his displayName? (I suppose so, since you said "problem occurs when he first logs in again"). Did Brent clear his browser cache before logging in again?
Did you try to:
1. Correct Brent's LDAP displayName and Bugzilla's profiles.realname.
2. Change Brent's password to something temporary.
3. Login witth Brent's account and temporary password?
And if the above all fail...
Can you try to update my LDAP account's displayName and cn, and see if my tracker display name changes? I'm gonna log out after this, so we can test for my re-login later.
Has modify.php tested to be working, including for the updating of "Real name" only (without typing in email address)? Did Brent try to update his own "Real name" via modify.php? Not that we need to correct modify.php now; personally I don't use it.
> > A few things I need you to do:
> > - Duplicate the tracker wholesale, codes and DB
> > - In the duplicate...
> >
> > Can you do that?
>
> You just want a copy of the code and DB, not a working instance on another VM?
Yikes, I just realized it's NOT merely Bugzilla. Yeah, if you can provide a VM, that'll be good. We can debug together. Easier for me to replicate the on-site issues too.
If no VM for me, I'll have to install OpenLDAP (for Windows) and all.
Seems unlikely the issue is in the SSO login. Thin wrapper only. I would check from Bugzilla's Bugzilla::Auth::Verify::LDAP. And then Bugzilla::Auth::Verify->create_or_update_user().
> I looked in the spec file for the SRPM, and found these two patches
> being applied
Those 2 patches don't seem like what we're looking for. Ok, so the Bugzilla files weren't hacked. Let's move on.
> Our template customizations are here
Unlikely too. I believe you only touched the "View" and not any logics. Still, I'll check this last.