-
Notifications
You must be signed in to change notification settings - Fork 14
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
Builds out roles + role-specific landing UX + tighten up auth guards #455
Conversation
…e pre-added by case manager or admin
}; | ||
|
||
// Function to compare roles | ||
function hasMinimumRole(auth: Auth, requiredRole: UserType): boolean { |
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.
this function assumes that each role is a superset of the prior one; does this mean a case manager should be able to do what a para does?
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.
Yes. Uncommon work flows could be removed from the UI, but I'm thinking in the future there could be an administrator panel that could change database records through trpc calls
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.
Yes, @nickvisut for now cascading roles on the backend seems like a good fit for POC/MVP. And as mentioned by Vince, the front-end doesn't do much in the way of auth guards, it just hides ui, but entering a route by hand will render the page, even if the api won't fill the page with data. We can add stories for those use cases as well.
}; | ||
} | ||
|
||
export enum UserType { |
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.
nice!
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.
Honestly I'm wondering if it would be possible to just use the default TypeScript enum where UserType.User = 0, UserType.Para = 1, and then use it as our ROLE_LEVEL, and instead have some fixed function called getUserTypeString(userType: UserType) that returns "user", "para", "case_manager", "admin", and is used only for writing to the database, which stores these strings rather than the enum.
added Compass Engineering Reviewers as test of the new team |
await trpc.case_manager.addStudent.mutate({ | ||
first_name: "Foo", | ||
last_name: "Bar", | ||
email: "invalid-email", |
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.
Nitpick: this shouldn't be an invalid email because that's not what we're testing. I'm going to fix this
|
||
export interface GetTestServerOptions { | ||
authenticateAs?: "case_manager" | "para" | "admin"; | ||
authenticateAs?: UserType.CaseManager | UserType.Para | UserType.Admin; |
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.
Do we want to just set the type to UserType, and make it default to UserType.User if it's not specified?
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.
^^ Just tried this, there's not much benefit because the seed file doesn't have a "UserType.User" key so it becomes more trouble than it's worth
import $box from "@/styles/Box.module.css"; | ||
import $typo from "@/styles/Typography.module.css"; | ||
|
||
const SorryPage: React.FC = () => { |
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.
If we aren't going to use this element in this PR, let's remove it and add it to a new branch split from this one.
}); | ||
|
||
test("getMyTasks - regular users don't have access", async (t) => { | ||
const { trpc } = await getTestServer(t, {}); |
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.
See my comment on making authenticateAs default to UserType.User if not specified, and have authenticateAs just have type UserType
to test:
--> user goes to /sorry
--> para goes to /benchmarks and has limited nav menus
--> case_manager goes to /students and has appropriate nav menus
--> admin goes to /students but has all nav