-
Notifications
You must be signed in to change notification settings - Fork 0
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
173 feature rough department and position onboarding page #185
base: main
Are you sure you want to change the base?
173 feature rough department and position onboarding page #185
Conversation
give all people all options, but disable if they already have a position / department respectively
if person already has a dept/position it should show in dropdown as default and be disabled
A couple of spacing / lines I didn't mean to change
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
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.
It looks like we won't be able to register an employee because userData, email, password, departmentName, and positionName will be null in register.tsx.
There is a way we can get around this by exporting that data from auth context or saving it in local storage, but the changes will take a while and I don't want to rush so we can discuss during GM.
Description
I created a new page called register that the user is rerouted to when either their department or position is empty. The page tracks their department and position selection, and when they click submit, calls back to AuthContext to register them. If either a position or department is already in the database, the respective field is disabled on the selection page. Submit is disabled until a position and a department have been chosen. As of right now, there are no restrictions on what combination of department and position a user can select.
Also, I added a function to the AuthContext interface to complete registration of a new user.
Motivation and Context
When MFA members log in for the first time, their email might not be associated with a department and position, but we need to enforce that they have this information to use the site.
Closes [#173]
How has this been tested?
I tested the rerouting and selection updates by temporarily forcing all users to go through Register and logging the selections and fetched data. I was able to walk through the onboarding process. I will note, I was testing through a northeastern.edu email, so I wasn't able to test the submit functionality (it relies on auth database and therefore is unable to find a northeastern user). However, this won't interfere with us logging in using northeastern emails as long as they are preinitialized with a position and department.
Screenshots (if appropriate):
Types of changes
Checklist: