Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bugfix: allow Clever takeover if email is already taken #20519

Merged
merged 6 commits into from
Feb 9, 2018

Conversation

ewjordan
Copy link
Contributor

@ewjordan ewjordan commented Feb 9, 2018

  1. Don't store emails for Clever students
  2. Force Clever takeover for teachers if email is already in use

This should resolve a lot of the Zendesk tickets that we have, because we don't currently allow Clever account takeover when the email is already in use. Now there will be a flow that allows (and in the case of teachers, forces) people to connect if their email is already in our system.

user.email = auth.info.email unless user.user_type == 'student' && auth.provider == 'clever'

if auth.provider == 'clever' && User.find_by_email_or_hashed_email(user.email)
user.email = user.email + '.cleveremailalreadytaken'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Possible bad edge case, I'm not sure though.

If we're creating a new student account, line 625 is a no-op so user.email is nil or blank?
Then if find_by_email_or_hashed_email finds a user with a blank email (presumably possible?) then line 628 sets the email to nil.cleveremailalreadytaken or just .cleveremailalreadytaken. We'd also probably end up with lots of users with that email, which might cause validation errors/conflicts later?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just did a check on prod:

irb(main):013:0> User.find_by_email_or_hashed_email('')
=> nil
irb(main):014:0> User.find_by_email_or_hashed_email(nil)
=> nil

Seems like we might be okay?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will we stay okay though? Assuming 627 evaluates false we don't set user.email at all, so then in the future do we end up finding a user with an empty email?

@@ -95,5 +95,6 @@
cleverLinkFlag: "#{session['clever_link_flag']}",
userIDToMerge: "#{session['clever_takeover_id']}",
mergeAuthToken: "#{session['clever_takeover_token']}",
forceConnect: "#{session['force_clever_takeover']}",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this need to be a string, or can we convert it to a boolean here right where the value gets stored in JavaScript, instead of inside the React component?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good call, will make this change.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, I tried to fix this, and it seems to have seriously broken some stuff, so I'm going to put this off - ultimately this code will be going away, so it'll disappear at that point.

Copy link
Contributor

@islemaster islemaster left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Generally looks really good, I have one nit and a question about possible email conflicts.

@ewjordan
Copy link
Contributor Author

ewjordan commented Feb 9, 2018

Going to go ahead and merge for bug bash, will revert if we find issues - the failing test seems unrelated to my changes.

@ewjordan ewjordan merged commit a1f4f18 into staging Feb 9, 2018
@ewjordan ewjordan deleted the widen-reach-of-clever-takeover branch February 9, 2018 22:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants