Update magic links to indicate a user should be created

[mjrb]

once completed Make a frontend issue

[hemangandhi]

I don't understand why.

This could cause a few bugs in the process: there shouldn't be any relation between promotion links and whether the user exists since there's no way to enforce that.

Why do you want this?

[mjrb]

There is a special case for forgot password where it prepends something special to the beginning of the link so the UI knows to show the forgot password dialog. In order for the UI to jump to the signup dialog for create consume we MUST have some way to communicate that to the frontend. The only other way is like arbitrary unauthenticated user lookup (not good). Or potentially changing the landing route, in which case forgot password needs to be changed too. This issue may be solved by jwt for magic links, but I mostly opened this issue Because it this is the second semester where create consume is just going to have bad ux

[hemangandhi]

Makes some sense. Just adding some historic notes to explain the weirdness. TL;DR: I guess the frontend can have some sort of signal to know what kind of promotion it is passed, but it wouldn't be perfect all the time.

NGL, that was generally just the weirdness we always had: we don't want to assume that

1. A person getting promoted isn't a user.
2. A person getting promoted is a user.
3. The person getting promoted uses the same email to sign up as they did to get the magiclink.
4. If the person wasn't in the DB on magic link creation time, they won't be on consumption time.

These are all pretty messy for the frontend, but assuming any of them can make the UX bad for certain types of user -- we didn't want to make these assumptions since we assumed that users would come from pretty much anywhere, including sponsors and judges.

[mjrb]

For 1 and 2, we can make those assumptions lcs has the db. 3 will be fixed by the jwt thing which forces them to use the email they created the magic link with. 4 if an account is created in between create magic link and consume then we're kinda fucked. maybe we should make a check magic link endpoint to get a recent view of the situation instead. This way the frontend won't have to make assumptions/work with old data

[hemangandhi]

Yeah, we didn't make 1 or 2 because we didn't know which was better. 3 excites me, we used to assume this and then I was told not to. Yeah, 4's a mess, but perhaps you can re-email people in this situation when they make their account (especially once you assume 3).

I'm glad this is getting cleaned up.

[mjrb]

i think that may actually be the way to fix this, to create a read magic link endpoint, that gives

• the user's email
• if its a promotion link or reset link
• maybe some other data