Subscription management unideal: No error messages, no opt-out #336
Description
On the positions/:id/edit page:
Two very related issues came to light today for me. The context: I was trying to subscribe to email notifications with my work email instead of my personal email. I unsubscribed with the personal email, and tried to add my work email. That produced no error and no output, as if it entirely didn't work. Are the tests bad, I thought? But no--subscribing literally any other string worked like a charm.
It took some serious digging in the console to realize the truth: @sherson had created a subscription for me with that email (I had, while distracted, answered 'my work email' when he asked which email I wanted associated with the current set of IT applications.
Now, this isn't a problem for me because I can just fix this for myself, but the truth is that anyone could subscribe anyone else to our job application notifications and the "subscribee" could do nothing to stop it.
I propose we do what every other subscription service online does and that's have a confirmation process. Until a subscription is confirmed (I envision a boolean on the Subscription model), no subscription emails should be sent.
The related issue and one that would have saved me a lot of digging is simply a displaying of any error messages when creating a subscription. Had I known I was violating a uniqueness constraint I'd have been able to ask the right questions. A simple flash message would suffice--the create action has no error handling.