[Moderation] Add User Status Checks on Endpoints

[AkshayPall]

1/3 PRs for #224, ensuring that a user who has been banned/deleted recently will no longer be able to interact with the site.

The next 2 PRs will be to (1) Update all views for other users so they no longer see the usernames of deleted/banned users and (2) Add support for banning + deleting users (as admin or yourself).

[AkshayPall]

I know we've stuck to lookup tables for Site Roles however I don't imagine the UserStatus field to grow in value. If anyone thinks there is a nonzero chance of this, please let me know and then I can create a separate UserStatus table.

[akprasad]

Thanks for this!

I want to think through the active/deleted/banned distinction a little more. It looks like a given user always has one of these three states, but I think there are other states we could consider as well, such as:

• An unverified user who hasn't confirmed their email address yet.
• A user who's banned for 1 week.

If we're very sure that this set won't meaningfully change, it might be better to have date flags like activated_at, deleted_at, banned_at, where the field is either set (= true) or null (= false)

I find it helpful to see how Discourse models their user data: https://github.com/discourse/discourse/blob/main/app/models/user.rb#L1988

[AkshayPall]

Adding unverified state is definitely useful - I can see us gating certain functionality behind it.

I don't think we'll have any other statuses beyond the 4 mentioned - I think the idea of adding temporal annotations statuses seems to suggest a creation of a UserStatus Log / HIstory Table, which is just a running log of all status changes for a user with the timestamp and potentially a "previous action" column that stores context as to why the status change occured.

So in total, the Table UserStatusHistory would have columns (id, timestamp, user_id, status, explanation).

Mentally, I am modelling the state machine of Users to have 4 states (statuses) that I don't expect to change much but I feel we may introduce a variety of policies for moving between them (edges) often enough to keep them separate. What are your thoughts on implementing this approach?

[akprasad]

What are your thoughts on implementing this approach?

I like it in principle, but this view of the world assumes we can model user states as a simple finite state automaton where 1 state = 1 node. But I think there are reasonable semantics we can associate with combinations of states, and having just one state can potentially lose information.

For example, I think it's meaningful to distinguish between deleted and banned and deleted and not banned if a user wishes to have their account reinstated for whatever reason. Likewise I think it's possible to have combinations like banned and not verified (e.g. if we allow limited activity without verification).

Using dates as a truth value is something I haven't done before, but it's a way to get bookkeeping for cheap without much complexity elsewhere in the stack (e.g. with a separate audit log). I do think we should have an audit log, but that's less urgent.

So although it feels clumsy, what do you think about having simple columns like:

# using booleans for illustration, but a similar principle applies if we use dates

# whether the user has a verified email 
is_verified
# whether the user is banned
is_banned
# whether the user's account has been deleted (deactivated?)
is_deleted

and managing the state this way?

[AkshayPall]

Ah I see, you make a fair point about having "multiple states at once". Let's stick to the columnwise approach and, like you said, create the audit log of "state changes" later on once the banning/removing functionality gets added.

[akprasad]

Thanks for waiting -- this broadly LGTM.

[akprasad]

Why use setters instead of user.is_deleted = True?

[AkshayPall]

To be consistent with set_password as a property that is modified after-the-fact (and I'm biased with my previous Java experience haha). I can remove it if it's too verbose.

[akprasad]

set_password is kind of a special case to abstract away the password hashing logic. Otherwise I think plain attributes are more manageable long-term

[akprasad]

@epicfaace ^ looks like the docker-setup is failing here -- can you help debug?

Merging because fixing the docker issue might take a while and it seems unrelated to this PR.