add soft delete for users and permissions

[harishv7]

Notes

1. Do not merge till security review
2. Requires expanding migration

Problem

Closes ISOM-1701

Solution

Breaking Changes

• No - this PR is backwards compatible

Features:

• Added soft delete functionality for Users and ResourcePermissions via deletedAt column
• Added user deletion check during email authentication flow

Improvements:

• Enhanced permission queries to exclude soft-deleted records
• Added filtering for deleted users in ongoing sessions

Bug Fixes:

• Fixed potential security issue where deleted users could still access the system with active sessions

Tests

• Verify soft delete functionality for Users, by setting deletedAt to any valid timestamp
• Users with deletedAt in the User table should not be able to login
• Users who are already logged in with an active session should be logged out when the deletedAt is set in User table
• Users can have Resource Permissions to several sites. If a Resource Permission is set, then the User should not be able to see that specific site in the All Sites view. Visitng the deleted resource Site's URL directly should show that they are unauthorised to view the page

New scripts:

• 20241220130729_add_deletedat_user_perms : Adds deletedAt columns to User and ResourcePermission tables

[harishv7]

• add tests and handling for deleted users #953
• add soft delete for users and permissions #952 👈 (View in Graphite)
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[datadog-opengovsg]

Datadog Report

Branch report: 12-20-soft_delete_for_user_and_perms
Commit report: 4d4bdc9
Test service: isomer-studio

✅ 0 Failed, 257 Passed, 36 Skipped, 45.46s Total Time
➡️ Test Sessions change in coverage: 1 no change

[linear]

ISOM-1701 Enable soft deletes for user management

[adriangohjw]

curious, it seems like this solution isn't "audit complete".

For example, how do we handle situation where agency wants to restore a user's permission for a site's resource? we cannot add another record due to ResourcePermission's @@unique([userId, siteId, resourceId, role]). We can remove the deletedAt but it will mean remove the audit trail aspect of it

It's alright if this is a stopgap measure, but just want to clarify that this is intentional

Not urgent but we might also want to add a backlog ticket to write a script to automate this.

[harishv7]

@adriangohjw this measure is to support soft deletes for now. In terms of audit completeness, we will have to re-look into that in ISOM-1072

To re-store a user's permissions, we will need to remove the deletedAt in User table. For ResourcePermission we will add a new entry. To find out the audit trail, we can check based on the userId when were the resource permissions removed fully and re-added.

Couple the above with Ops email/Slack request, there is still some kind of full audit picture. Lmk if that makes sense!