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

feat: add endpoint to invite users #343

Merged
merged 9 commits into from
Nov 27, 2023

Conversation

ojeytonwilliams
Copy link
Contributor

@ojeytonwilliams ojeytonwilliams commented Nov 17, 2023

Builds on top of #342 (please don't merge until that's in!)

The workflow this allows is

  1. create a user via POST /api/auth/local/register
  2. invite that user via PUT /api/auth/invitation/:id

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 from user.role. It's not hard to understand, but it was extra complexity.

@ojeytonwilliams ojeytonwilliams requested a review from a team as a code owner November 17, 2023 16:18
@sidemt
Copy link
Member

sidemt commented Nov 21, 2023

@ojeytonwilliams Thank you for this proposal.
I haven't checked the new flow thorougly, but a few things I wanted to note:

  • In our use case, editors are most likely to be someone from the staff team, so we wanted to simplify the roles into 2 types, Editor and Contributor.

  • Users (both editors and contributors) will only use the Next.js app and will not use the Strapi admin panel. So we will still need the /users page (linked from "Staff" in the menu, the file is src/pages/users/index.js) and the user invitation functionality in there.

We can discuss this in the upcoming platform team meeting.

@ojeytonwilliams
Copy link
Contributor Author

ojeytonwilliams commented Nov 21, 2023

In our use case, editors are most likely to be someone from the staff team, so we wanted to simplify the roles into 2 types, Editor and Contributor.

Thanks Yoko, I'll adjust #350, but this PR should be okay.

Users (both editors and contributors) will only use the Next.js app and will not use the Strapi admin panel. So we will still need the /users page (linked from "Staff" in the menu, the file is src/pages/users/index.js) and the user invitation functionality in there.

Yep, understood. I'll put it back in before I'm done updating the invitation flow.

Copy link
Member

@Nirajn2311 Nirajn2311 left a comment

Choose a reason for hiding this comment

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

LGTM

@Nirajn2311 Nirajn2311 requested a review from sidemt November 23, 2023 12:54
@sidemt sidemt enabled auto-merge (squash) November 27, 2023 14:27
@sidemt sidemt merged commit 35f62de into freeCodeCamp:main Nov 27, 2023
7 checks passed
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.

3 participants