Closed hiyaryan closed 9 months ago
Last commit implements the full mechanism for beta approval. See expanded commit message for an exhaustive list of changes.
Before closing this PR it is worth refactoring the repeated code in all of the User methods that send emails. It is also a good opportunity to update the messages that don't have proper greetings and closings.
Very important for existing users, set betaAccess
in their User model data to true
. This can be done on login. When a user logs in after beta testing is closed, their is an opportunity to check it betaAccess
is undefined, if so, set it to true
.
Once beta has been closed, set the API Key for all users to be a shared API Key. Then in a separate PR determine what to do with Config. One idea is to remove it completely, but another idea could be to keep it, remove the API Key block (or replace it) and allow users to select their own models based on the tiered system in development.
Release phase has been added to the Home page under the title. It is interpolated into a Typography component when the frontend is built using environment variables.
In addition to the previous note the mechanism for email verification has been built. That is enough for this PR as it still relates to the overall beta tester purpose. (FOR NEXT PR) This mechanism should be incorporated in general into the app. A user can not reset their password if they can't access the email they're using to sign in! If a user is verified add a blue verified ribbon icon next to their email in Account.
This PR establishes release phases. The initial commit sets up a beta user request route with email verification.
Specifically, if the release phase is beta, when a user registers they will be asked to verify their email and await a message with a special link to gain beta access through the
requestBetaAccess
middleware along the registration route. TherequestBetaAccess
middleware creates a new user without a password preventing the user from being able to login since passport is expecting a salt value.New fields are added to the User model for email verification that uses JWTs,
verifyEmailToken
,verifyEmailExpires
, andemailVerified
. A newverify-email
route has been added to both the API and frontend router. The frontend simply makes a request to that access API endpoint where averifyEmail
controller sets theemailVerified
User field to true. An email must be valid in order to receive the email. The client is then navigated to theLogin
page where they are flashed either a success or failure message.Closing this PR will close issues #81 and #42