Disable email confirmation.

[ashercodeorg]

In particular, this PR removes the sending of confirmation emails and the partial alerting the user that their email has not been confirmed. Further PRs will dismantle associated code (deleting the partial view itself, deleting the confirmation email, updating our devise usage, and removing the associated DB columns).

[ashercodeorg]

@poorvasingal and/or @ryansloan to confirm we do still want to deprecate our usage of confirmable.

[jeremydstone]

LGTM, pending your being sure (per your comments on the PR) that this is a change we want to make.

[poorvasingal]

I can't think of a reason right now for why we'd want to keep this feature. But I wouldn't be surprised if we wanted to add it back in when we start thinking about parent accounts. I think that feature will be different enough though (e.g. it'll be an email asking the parent to confirm that they are okay with their child having their own account).

[ashercodeorg]

@poorvasingal: Since our (past) usage of email confirmation is tied to the Devise::Models::Confirmable module, this feature is fairly restricted in flexibility. If we were to want to store a parent email, that would be a very different feature for which we should be using another solution.

[joshlory]

Does this mean we no longer confirm teacher account email addresses?

[aoby]

@joshlory yes, this is the email address confirmation email that goes out automatically when a new teacher account is created. We have a different concept of validated / confirmed teachers, that enables parts of the UI (I don't know too much about this part), which needs an upgrade but is currently handled by the cohort model.

[ashercodeorg]

@joshlory: Yes, as @aoby notes. This feature was a frequent source of zendesk tickets, a frequent source of confusion, a PII leak (for some time, we accidentally stored a student email if they started as a teacher, modified the email without confirming it, and switched to a student account), and never used (in that nothing changed before or after confirmation).

@aoby: My guess as that you are thinking of authorized teachers which (for example) solution access for some levels is gated on.

[ashercodeorg]

FYI @caleybrock, this is expected to change any eyes tests that happened to capture the alert. My intent is to accept any new baselines that arise from the robo-DTT this AM.

[aoby]

Yes @ashercodeorg that's it: authorized teachers. Thanks! Long term we need to remove the cohort dependency, but that's another story.

[ashercodeorg]

Do we have any idea what will eventually replace the cohort dependency?

[aoby]

No. We have talked vaguely about making a new model (or property on user) for this purpose, but nothing concrete.