-
-
Notifications
You must be signed in to change notification settings - Fork 11
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
feat: add endpoint to invite users #343
Conversation
190f3b6
to
9e36391
Compare
@ojeytonwilliams Thank you for this proposal.
We can discuss this in the upcoming platform team meeting. |
Thanks Yoko, I'll adjust #350, but this PR should be okay.
Yep, understood. I'll put it back in before I'm done updating the invitation flow. |
9e36391
to
a4a917c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Builds on top of #342 (please don't merge until that's in!)
The workflow this allows is
This creates a user that can only be logged into via Auth0 and sends them an email letting them know they can log in.
To be defensive we can create the user
blocked
and with long random password, but the main protection is that will disable the email provider in production. It prevents email/password logins, but not registrations, so does not interfere with this workflow.Why?
This simplifies the invitation process and decouples it from registration. We no longer need to maintain a separate content-type whose purpose was to prevent self-registration. Instead we can allow registration only by Administrators.
It also simplifies roles. When I was trying to understand how user registration worked, I was confused by what
invited-user.role
did and how it differed fromuser.role
. It's not hard to understand, but it was extra complexity.