You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
Worth noting that 'every other subscription service online' probably aren't enterprise solutions. Slightly different context with different expectations of user buy-in.
I didn't mean that because every other subscription service does it that we should do it, but as an example of a pretty solid process to prevent mistakes.
Do I think that anyone using this application is going to sign someone up without their consent? No. Do I think it's possible to do so accidentally? I've received enough emails for someone named "Katie Eichelman" to say yes. Her email is one letter off from mine.
I wouldn't want to send the names of all our applicants to some random person by accident, basically.
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.
The text was updated successfully, but these errors were encountered: