Closed Bug 1042775 Opened 11 years ago Closed 11 years ago

Event auto-vouches disappeared on staging

Categories

(Participation Infrastructure :: Phonebook, defect)

x86
macOS
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED INVALID

People

(Reporter: rbillings, Unassigned)

References

()

Details

(Whiteboard: [vouching rel. 1])

Testing on staging this morning I had 4 vouches: 1 for being staff, 3 for attending each Summit day. Within the hour the Summit vouches disappeared, and I only see the one vouch left: https://mozillians.allizom.org/en-US/u/rbillings1/ Repro's on multiple browsers.
If "morning" is earlier than 8.00 am PDT then it happened because we're dealing with a database problem and we re-loaded the data from a backup (bug 1041556). Can you please verify Rebecca?
Flags: needinfo?(rbillings)
I can verify that I still do not have event vouches- when I know I had them earlier today. I can't say what time, it may have been prior to 8am. https://mozillians.allizom.org/en-US/u/rbillings1/
Flags: needinfo?(rbillings)
If it's prior 8am then not having the vouches is normal, we restored a database backup. I suggest that we mark this as incomplete unless we have more data to investigate the error.
rbillings has a valid point in that stage has historically been a place where our test accounts and the data contained in them persists, allowing us to do proper integration testing.
Giorgos: prior to 8am I DID have vouches, now, later, I do NOT have vouches when I should. At least if you are backing up from prod then I should have 3 vouches from the Summit.
This was profile confusion, due to the database import rbillings wasn't able to login to her actual profile because of the email anonymization. We probably need a way to flag accounts to avoid anonymization other than setting them to staff/superuser.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → INVALID
Status: RESOLVED → VERIFIED
(In reply to Andrei Hajdukewycz [:sancus] from comment #6) > We probably need a way to flag accounts to avoid anonymization other than > setting them to staff/superuser. Nice suggestion, sancus. I filed bug 1043621 for this.
You need to log in before you can comment on or make changes to this bug.