Functionality to "disable" users and orgs

[CarlosNZ]

It should be possible for users and organisations to be "removed" from the system. But we don't want to actually remove the database entry, as that would also erase their connected applications. Suggestion is to add an "enabled" field to both the user and org tables, which we can set to "false" when disabling a user.

Work required:

• Update database schema to add "enabled" fields (with default value true)
• Update login functionality to ignore disabled user/orgs
• Create form to disable/re-enable users (process TBD)
• Update data views to exclude disabled user/orgs
• Update User/Org reg templates to create user on submit, as per this comment
• Make new build, test

Estimated work 1.5 day (probably less, but probably will require a bit of back-and-forth about the best way to present/filter the data views)

[craigdrown]

and time to convert dashboards etc to only show enabled?

A temp fix: can an admin change the user's password, and also change their email address so they can't password reset?

[CarlosNZ]

and time to convert dashboards etc to only show enabled?

Most dashboards are applications-based, so wouldn't want to change anything on those ones (historical applications should still show disabled users/orgs). Simple lists of users/orgs are viewed/filtered in the app.

A temp fix: can an admin change the user's password, and also change their email address so they can't password reset?

Sure, but they won't be filtered out of lists of users/orgs.

[CarlosNZ]

This would also solve a known existing edge case. Currently, if another person signs up with the same username as someone else who's already submitted their application, but hasn't yet verified (i.e. the user won't be created yet), then the 2nd person won't get the "username must be unique" error, but their application will fail once they try to verify (if the other user has verified in the meantime).

The solution to this problem would be to create the user immediately on submission, but in a disabled state, and then when they verify we just set it to "enabled". Then another user wouldn't be able to use the same username at all.

We'd also need to add a scheduled "cleanup" on submission which would delete the user if not verified within the verification timeframe, so as to not pollute the system with a bunch of "dead" usernames that were never fully completed.