Moderation log

[Toastbrot236]

This PR offers an initial implementation of a moderation log; mostly preparations and filtering.

Moderation events are stored as Events, just like activity events. They're seperated by the new EventOverType enum value, which replaces the IsPrivate attribute so the server could more precisely control event visibility and properly inform API clients on which events are activity and which are moderation. Activity events are still visible to everyone, while moderation events are only visible to their actor, the involved user (publisher/owner of the event object) and any admin (also moderator in the future).

Events can now also hold a description (useful to put a moderation reason there), the foreign key of the involved user, and a IsModified flag, which both reduces the amount of EventTypes nessesary, and is similar to how the game differenciates between level/review initial upload and update events.

EventType now has more custom types, mostly for moderation, and EventDataType now has more data types like playlists and assets for use in the future. There is no new grouping behaviour for those data types, so events referencing them will not be included in responses. I've only added moderation event creation calls to 2 admin endpoints so far, to keep this PR from becoming too large while still already demonstrating that functionality.

Events will no longer be deleted when deleting their objects, since deletion actions (especially by staff) are also interesting for a mod log, and the events of deleted objects might be generally useful for moderation. Their visibility will instead be restricted to be the same as for moderation events. In the future a PR should introduce timed deletion for those events, to not keep them forever.

The game will no longer receive custom events as these never get shown and only bloat responses anyway (especially bad once the server actually starts creating events using the other custom types), and it also won't receive moderation or deleted object activity events to not accidentally break anything. While API clients may already specify whether to filter moderation/activity/deleted object activity events, by default only activity and no other kinds of events will be returned to not break refresh-web or any other API client which can't handle these kinds of events yet. Grouping events for deleted/missing objects should work on the backend now, but again, those events are excluded from responses by default as they break the website.

I've quickly tested most of these changes with some unit tests (which I haven't included in this PR to not make it too large again), and also using lbp2, refresh-web and postman, but I do encourage you to test this yourself aswell.

[jvyden]

Okay, this is another PR that's doing too much.

This PR makes several large refactors into how events are initialized, stored, and serialized, and then adding a whole new system on top of that. It's fine for one PR to do one big thing. It's even fine for a PR to do several 'small' things. But several big things in one PR is bad.

The notable exception is that tests are always fine to include. In fact I usually skim over them as I review - they don't need to be pretty, they need to exist at all.

This PR should be 2 or 3 PRs:

• Your changes to serialization behavior and initialization. Essentially, laying the groundwork for the event system to handle this.
• The changes to the database schema for events would also be welcome in a different PR but I can see how that would be annoying to do.
• Then, you can add new events, etc.

I also kind of disagree with using the Event system for this as it's already quite bloated and slow, not to mention how intertwined it is with game-related code. I quite enjoyed writing and using the Case system I created for Lighthouse, which doesn't use recent activity at all and exists as it's own system.

Something similar should be built for Refresh that can properly be expanded on. Using Events limits those options.

[Toastbrot236]

Ok, what do you think of this:

• one PR to introduce a different entity for moderation action (which will initially have similar attributes as Event though, since I don't see much of a difference in that aspect) aswell as methods to add those to the database and fetch lists of them,
• then another one for actually inserting the creation calls into the admin endpoints
• then or before that a PR for fetching moderation actions from the API,
• and in parallel maybe another one to handle missing/deleted event objects.

[jvyden]

That sounds good to me. 👍