Adds end-to-end feature for archiving and deleting user accounts

[agosmou]

Summary

This PR solves #1395
Implemented an end-to-end feature, creating a workflow that allows security admins to archive, un-archive/restore, and delete users along with their corresponding projects.

• Update 10/26/23 Creates Test Plan for Running Integration Tests on Server API Endpoints #1493:
  • Testing plan created and implemented for these account routes and the existing account routes
  • Server-Side Testing Wiki Created

Features

• Archiving Users: Security admins can now archive users.
• Un-archiving/Restoring Users: Security admins can also un-archive and restore users.
• Deleting Users and Projects: Security admins can permanently delete users and the user's respective projects.
• UI Enhancements: Added buttons and confirmation modals to ensure admins understand the implications of their actions.

Technical Details

• Created a migration script to alter the tables "Login" and "Project" to add an archivedAt column that is set to NULL by default or to a timestamp if queried
• Created new, protected API endpoints:
  • Accounts:
    • PUT /api/accounts/:id/archiveaccount
    • PUT /api/accounts/:id/unarchiveaccount
    • GET /api/accounts/archivedaccounts
    • DELETE /api/accounts/:id/deleteaccount
  • Projects:
    • GET /api/projects/archivedprojects
• Added new components in the frontend to handle the workflow.
• added new frontend routes to show all archived users or all archived projects

How to Test

1. Login as a security admin.
2. Navigate to the /Roles page.
3. Next to each user, there should be an 'options' button(vertical ellipsis).
4. Clicking the 'options' button will render a PopUp that can be clicked to archive the user. This will populate the archivedAt field for the user and their projects; thus, 'archiving' the user. Security Admins cannot be archived or deleted. The user is also not able to self-archive or self-delete.
5. To see the archived users, navigate to the /archivedaccounts by following the link. Here, the security admin can 'un-archive and restore' a user OR permanently delete by clicking on the arrow or trash icons and their respective PopUp's. These actions will take effect on the user and their corresponding projects.
6. To see all archived projects, navigate to the /archivedprojects by following the link. This page only shows all archived projects - no actions. To return to the /Roles page, follow the link on the top of the page.

Feature Notes

• Deleting a user is irreversible - there is a currently a multi-step-process to delete a user to prevent accidental removal.
  1. select 'options'
  2. use popup to confirm user is to be archived
  3. Visit the archive page
  4. select 'delete'
  5. use popup to confirm user is to be permanently deleted
• Only Security Admins can archive, un-archive/restore, or delete users.
• The logged-in user cannot self-archive or self-delete
• Archived users cannot login

Future Improvements

• We could consider adding 2-Factor Auth such as email confirmation or PIN to delete users

Visuals

[agosmou]

Branch Notes

• I developed using a local db so the migration must be run on the shared development db
• 'prettier' was giving me tons of issues with line-endings as I developed on my windows machine so I made a fix on the /server and /client directories to mark the endOfLine property to auto
• The migration I did, using my local db, caused a large change in the /server/report.html and /server/report.json files (~6,000 lines)

[agosmou]

Ready for review!

Do note the comment above:

Branch Notes

* I developed using a local db so the migration must be run on the shared development db

* 'prettier' was giving me tons of issues with line-endings as I developed on my windows machine so I made a fix on the /server and /client directories to mark the endOfLine property to `auto`

* The migration I did, using my local db, caused a large change in the `/server/report.html` and `/server/report.json` files (~6,000 lines)

[entrotech]

This PR is FANTASTIC! I ran the migration against the shared dev db and it worked great, then tested all the features you implemented and they all worked perfectly, as far as I can tell.

There is a bit of overlap of your project archive feature with a different Issue that allows users to move their own projects to the trash and eventually delete them, but the purpose is a bit different, so we need to figure out if the admin delete/archive and user delete/archive for projects can just remain separate or not.

I had seen the report.html and report.json files crop up before, but didn't look into where they came from. It turns out the Flyway, the DB migration tool auto-generates these files. I read enough to know that they document the migration changes and you can somehow run reports on the migrations using them as source data, but we might look into their utility and see if we want to use them and figure out how to disable their generation if we don't. If we do want to use them, we should probably change the flyway config to give them better names, and tuck them away in the /server/db folder so they are out of the way.

Karandeep was also having trouble with line endings in Windows. We can talk about the relevant settings tonight.

I'm sure the UI designers will want to make some tweaks to the UI appearance, but the functionality is all there.