Add modlog entries for bulk removals.

[dessalines]

• Added unit tests for removal / restore to api_common/utils.
• Fixes Modlog should have entries for bulk-removed items, such as a result of a community/instance ban with content removal #4699

[dessalines]

Added these two helper functions that build the forms, although they could potentially be redundant with the create_multiple functions, which I could alter to take in all these params. Doesn't matter to me either way.

[dessalines]

Just removing some unwraps for these tests.

[dessalines]

New tests here.

[dessalines]

Diesel can do multiple inserts in the same statement, by taking in an array of forms. We should utilize this elsewhere instead of looping SQL commands (as long as we don't need the results).

[dessalines]

Just boilerplate removing the unwraps. Can ignore.

[SleeplessOne1917]

Probably better to use Option<&str> instead of &Option<String>.

[dessalines]

We used to do that actually, but it ended up being pretty pointless. Either one works, but &Option requires less transformations and is a little less verbose.

[SleeplessOne1917]

Is there any difference between this function and restore_user_data besides the boolean value that's assigned to removed? If not, you could make a function that's local to this module that handles the cases and accepts the removed bool as a parameter. e.g. a function with a signature like:

async fn remove_or_restore_user_data(
    mod_person_id: PersonId,
    banned_person_id: PersonId,
    reason: Option<&str>,
    context: &LemmyContext,
    removed: bool
) -> LemmyResult<()> {
   // Put logic here
}

And then remove/restore data can just be this:

pub async fn remove_user_data(
    mod_person_id: PersonId,
    banned_person_id: PersonId,
    reason: Option<&str>,
    context: &LemmyContext
) -> LemmyResult<()> {
   remove_or_restore_user_data(mod_person_id, banned_person_id, reason, context, true).await
}

You could also use a const generic if you prefer:

async fn remove_or_restore_user_data<const REMOVED: bool>(
    mod_person_id: PersonId,
    banned_person_id: PersonId,
    reason: Option<&str>,
    context: &LemmyContext
) -> LemmyResult<()> {
   // Put logic here
}

And the public function would be:

pub async fn remove_user_data(
    mod_person_id: PersonId,
    banned_person_id: PersonId,
    reason: Option<&str>,
    context: &LemmyContext
) -> LemmyResult<()> {
   remove_or_restore_user_data::<true>(mod_person_id, banned_person_id, reason, context).await
}

[dessalines]

If you read through those two functions, they're different enough that it makes sense to keep them separate. The remove user data does a few extra things that the restore can't, like:

• purging their images
• clearing their profile images
• removing communities where they're the top mod

Whereas the restore can really only restore their posts and comments.

[Nutomic]

Should be easy to handle those inside an if is_remove block.

[dessalines]

Alright I'll give that a try.

edit: k that's done now.

[SleeplessOne1917]

Same as here.

[SleeplessOne1917]

Same as here.

[SleeplessOne1917]

Same as here.

[Nutomic]

This can probably be removed too. Otherwise change it to expect.

[Nutomic]

With this PR, banning a user with remove content that has some dozens of posts and comments will absolutely flood the mod log of all federated instances. A better solution would be to change ModBanView and ModBanFromCommunityView so that it also includes a list of removed posts/comments by that user (limited to the last 10 items to avoid huge api responses).

[dessalines]

I don't think there's any way to avoid many modlog entries. A mod remove post is a different type and mod action, and is a filterable field.

The main reason people want this, is so they can see all the posts and comments that got removed when an account was banned. There wouldn't be a good way to filter and see all those unless they have their own proper entries.

[Nutomic]

It would be possible to filter for posts which were removed as part of user ban with a separate query, and then merge the results. Shouldnt be too complicated really.

[dessalines]

I'd rather not add hierarchies of moderated items rn. Its okay if the modlog has lots of entries anyway, as those are all currently filterable by the type of action.

[Nutomic]

Should also be expect.

[Nutomic]

Alright lets do it this way. At some point we should think about removing old modlog entries to reduce the db size.