Some site person ban fixes, and code cleanup

[dessalines]

I've done a few cleanups here:

• The instance_actions join for most queries was incorrect. Fixed instance_actions to include:
  • instance_actions (you -> community item's instance (or occasionally the target person's instance))
  • creator_home_instance_actions (creator -> community item's instance)
  • creator_local_instance_actions (creator -> your local instance)
• Abstracted a lot of the common joins, instead of copy-pasting them everywhere.
  • I left a few alone, such as those in reports, since it starts to get complicated when there are 3 users involved (reporter, resolver, creator)

[Nutomic]

So in all these cases it is only for bans, not for blocks right? So it would be better to rename the struct to InstanceBan, and make a separate struct for InstanceBlock.

The field names are a bit confusing now, I would suggest changing like this:

• instance_actions (you -> community item's instance (or occasionally the target person's instance))
  • Change to my_community_instance_ban
  • Comment: Ban action from the community's instance against you
• creator_home_instance_actions (creator -> community item's instance)
  • Change to creator_community_instance_ban
  • Comment: Ban action from the community instance against post creator
• creator_local_instance_actions (creator -> your local instance)
  • Change to creator_local_instance_ban
  • Comment: Ban action from local instance against post creator
• Here seems to be an item missing where the creator is banned from his home instance, called creator_home_instance_ban with comment Ban action against the post creator on his home instance.

I also wonder if it is really necessary to include so much detail. Most likely frontends wont bother to display each item separately. So I would only include a single field instance_ban which is simply the first non-null value of all the above. Thats enough to show a "Banned" badge in the UI, and this badge can contain a link to the modlog for the user. That way its possible to see all the bans against that user in detail, without cluttering the UI and API.

[dessalines]

So in all these cases it is only for bans, not for blocks right? So it would be better to rename the struct to InstanceBan, and make a separate struct for InstanceBlock.

Its for both bans and blocks, for both you, and the item creator. We can't separate the structs, as we just spent a lot of time making sure these views only do simple joins to the actions tables.

creator is banned from his home instance

I think you're correct here, and I should add something to clarify whether its the community's instance, or the person's instance. The person could be banned from either local, the communities instance, or their home instance.

I'll:

• Rename instance_actions to either community_instance_actions or person_instance_actions
• Split creator_home_instance_actions into creator_community_instance_actions and creator_person_instance_actions

I also wonder if it is really necessary to include so much detail. Most likely frontends wont bother to display each item separately.

Some apps might find it useful to differentiate these visually, IE was this person banned from their home server, the community's, or mine? So for now at least I'll avoid adding a banned and let front ends do helper functions if they want to simplify that.

[Nutomic]

Some apps might find it useful

Are you going to implement this in lemmy-ui or jerboa? There are lots of things which might be useful but we cant implement everything. And this sounds like it will remain forever unused, making the api more complicated for no reason.

Another problem is that post_view and comment_view queries have too many joins now (11 each). These are critical for performance so it should remain below 8 as discussed in #5555.

[dessalines]

The joins are unavoidable unfortunately, we need to see if item creators were banned from those instances or not. But I didn't add the other join mentioned above, since these are getting excessive.

I added a creator_banned field, so that APIs can use it if they like. I'll keep the creator instance actions selects for now tho, I do see myself possibly using these in lemmy-ui.

I also added a unit test to make sure these are working correctly.