Create a superuser/admin with an UI to manage both CM and Para

[canjalal]

Related to #452 . We want users in the admin user role to be able to change the user role of every other user, and have a way to do it on the frontend. This will necessitate the creation of an Admin user page with a list of all users, and controller actions that will patch the user to change their role and/or delete them.

A related issue (see below) is creating a small number of users who can log in with username and password without OAuth, for ease of testing.

Notes

Per @nickvisut

would be cool tho to “impersonate” roles as admin for sure tho,
@Vincent Shuali

NEW

7:23
I think these are separate issues:
Adding impersonation via admin
Working roles/UI
being able to log in as para
another login auth

[tam-janice]

@canjalal to elaboate on this ticket and work together with Thom. This is higher priority than the other tickets on the board. We need to get this out before we are able to test and develop the other [Para] tickets

[thomhickey]

So regarding impersonation, I recommend that be an admin feature. So no one can impersonate admin, but admins can impersonate any other role. We can put a drop-down on the settings page that allows admins to set their role temporarily for the session. To regain admin, they would need to logout/in.

[tam-janice]

This ticket has a dependency on #452

[thomhickey]

I have the admin UI part of this working, preparing for code-cleanup prior to code review. @tam-janice @nickvisut @francisli @canjalal.

It has:

• shows all users
• paginated/sorted response from api + pagination/sort controls in the table
• search for users
• add user
• edit user including role
• an entirely new Table2.tsx that is totally generic and can be re-used by staff and student tables if we want
• it works!!

TBD:

• should the admin user who's logged in see themselves? probably not as if you bork something you can un-admin yourself?
• do we need delete/archive user? right now if you demote someone to 'User' role, they effectively can't do anything. we talked about how deleting/archiving is problematic if someone has data in the system e.g. a case manager with staff or a para with collected data.

[thomhickey]

check out feat/admin-panel if you want to see the code, but it's at the 'ai did a lot of this' stage, prior to me cleaning it up

[canjalal]

Wow thanks for the pagination!

I think the admin user who is logged in should be able to see themselves but not be able to change their own role, otherwise this could cause problems. They could be grayed out for example. There should be testing to ensure this is enforced both at the frontend and at the backend.

I think the delete/archive decision is complicated. Because as you said, we could lose data if we outright delete, but there could be security problems if we don't delete and just archive.

I am currently working on a PR to add storybook testing on frontend components