Do not write to users table email address columns

[mitchellhenke]

This has been retired for quite some time (almost 3 years), and it doesn't appear that we ever read email_fingerprint or encrypted_email_address from the users table since everything uses the email_addresses table

[jmhooper]

Does this update all of the users email addresses with a confirmed at date, including unconfirmed ones? That may be a problem. A user could add an unconfirmed email, send a password reset to a confirmed email, then confirm all of their email addresses including the unconfirmed one by resetting their password.

I'm not sure what impact bumping the confirmed_at on the email address record has. Since we aren't doing it now it seems like it may be safe to leave off if we can't easily get to the email the reset password token was sent to.

[mitchellhenke]

This is a part I'm trying to understand better, but I believe this is when you have an unconfirmed account, reset your password and then set the password, with the goal here being to set the account as confirmed.

This is stuff that would have previously been handled by the EmailAddressCallback here by setting confirmed_at on the user and setting the same value on the first email address.

The window is narrow, but I think we should probably only set it on the first email address (rather than all) like the callback and do all of this in a transaction to ensure things don't get weird in the time between checking the user has no confirmed emails in user.confirmed? and updating the confirmed_at.

[jmhooper]

Oh boy, yeah that is gnarly

[mitchellhenke]

I switched to that in fd2c310

[zachmargolis]

LGTM 🚢 🚀