Attach unresolved report counts to comment and post payloads

[aeharding]

Requirements

• [X] Is this a feature request? For questions or discussions use https://lemmy.ml/c/lemmy_support
• [X] Did you check to see if this issue already exists?
• [X] Is this only a feature request? Do not put multiple feature requests in one issue.
• [X] Is this a backend issue? Use the lemmy-ui repo for UI / frontend issues.

Is your proposal related to a problem?

When a mod is casually viewing their community, it can be helpful to see unresolved report counts on a given post/comment.

For example, imagine a post has four unresolved reports. Without viewing the mod inbox, the mod views the community. Lemmy can then show the mod that the post has four unresolved reports. The UI could then show the mod the report details, resolve the report(s) as needed and remove the post (if needed), all without viewing the mod inbox.

Describe the solution you'd like.

Comments and posts have unresolved report counts attached for mods (and admins?).

Describe alternatives you've considered.

You could fetch the entire mod queue and cross reference but that can be inefficient and doesn't scale well if mods don't keep the queue clear.

Additional context

• It may be helpful to provide resolved report counts alongside unresolved report counts so clients may convey if a post/comment has been previously "approved" by a mod
• It is critical to distinguish between resolved and unresolved counts, and not lump into a single report count (resolved + unresolved). See https://github.com/LemmyNet/lemmy/issues/4163#issuecomment-1813522204
• It would also be helpful if there was an endpoint to view resolved reports for a given post/comment, but that's a separate issue.

[aeharding]

I'd also like to note that this enhancement provides the opportunity to provide a mod queue by post/comment in Lemmy.

Currently, mods have to view each report as a separate entry via ListCommentReports and ListPostReports. This is tedious when the same post is reported multiple times.

Once comment and post payloads attach unresolved reports (as per the parent issue), Lemmy could simply provide a query parameter to GetPosts and GetComments with report_unresolved: true, for example. This would provide a queue of posts/comments that have been reported, but have unresolved reports.

Viewing reported posts and comments with reports grouped is a much nicer mod experience. This would also simplify Lemmy's API by rendering ListCommentReports and ListPostReports unnecessary. 🙂

[dessalines]

Similar to what I suggested in #4162 , we could provide a separate endpoint to list reports for a given item.

We'd have alter queries to join to the post_report table, and do a report_count for that, and if its > 0, link to that page where it shows reports for that specific item.

[aeharding]

@dessalines I'm fine with only adding unresolved_report_count to posts/comments, and not the entire hydrated unresolved report payloads, and then adding a separate endpoint to list reports for a given item.

However, as pointed out in https://github.com/LemmyNet/lemmy/issues/4163#issuecomment-1812769879, adding hydrated unresolved reports to posts/comments and a filter for report_unresolved: true to GetPosts and GetComment would make ListCommentReports and ListPostReports unnecessary, which would reduce the API surface. Just something to consider. :) It would also be simpler for apps, and a better moderation experience!

[dessalines]

That wouldn't be too doable since the GetPosts query is already a list, so it'd be joining lists to a list. Also reports and mod_table are mod/admin specific functionality, regular users shouldn't see that info anyway.

[aeharding]

OK! Well if hydrating unresolved reports on posts/comments isn't doable in the backend, then to summarize your proposal:

• add unresolved_report_count to posts/comments for mods/admins
• add endpoint to get reports by post/comment id for mods/admins

Optionally, it would be cool if we could also:

• add resolved_report_count to posts/comments for mods/admins
  • Clients could use this to show if a post/comment was already reviewed + approved by a mod, since resolved > 0 && !post.removed implies it was.
• add a way to filter GetPosts and GetComments by unresolved reports. (report_unresolved: true?)
  • In Voyager for example, I'd like to use this data to construct a mod queue

Would it be helpful if I closed this ticket and opened a new one, or modify this existing issue?

[dessalines]

I was thinking that rather than try to differentiate between unresolved and resolved, we just do an aggregate of all the reports (IE both types). It would work the same way for mod actions too, rather than trying to differentiate the type of action in the aggregate count. Otherwise we'd have to join to that table twice, and things could get complicated quickly.

add endpoint to get reports by post/comment id for mods/admins

Exactly.

These should really just be helpers / indicators, because mods should really work from the report queue anyway.

add a way to filter GetPosts and GetComments by unresolved reports. In Voyager for example, I'd like to use this data to construct a mod queue

That one isn't doable for reasons I described above, joining lists to sublists.

I highly suggest creating the reporting queue using the existing ListCommentReports and ListPostReports endpoints, like lemmy-ui does, to create your mod queue.

Would it be helpful if I closed this ticket and opened a new one, or modify this existing issue?

You can just modify this one, change the title, and copy some of your comment above into the top comment.

[aeharding]

Hey, hopefully this is OK to discuss here. I know this discussion is not specifically code-related but more architectural/planning so lmk if there's a better place to discuss!

I was thinking that rather than try to differentiate between unresolved and resolved, we just do an aggregate of all the reports (IE both types).

The problem I envision from this is that not differentiating between resolved and unresolved will make flagging a given post/comment as "needing attention" not possible. As an example, in Reddit, when there are unresolved reports on a given post/comment you see a yellow "X reports" banner on the post/comment [Apollo for reddit examples attached].

When the reports are resolved, the banner goes away. It's very important that the banner goes away once reports are resolved so they don't clutter the feed and make moderation more difficult by not knowing what's been actioned on or not. (Sorry not the best picture, I had to censor so I'm not doxxed on reddit)

Additionally, for posts and comments that have previously resolved reports, there is a checkmark next to the post/comment. This can be helpful because Apollo for Reddit showed whether a post has been "approved" already by a mod:

Again, I really think it's important to differentiate between resolved and unresolved count for a good moderator experience.

I highly suggest creating the reporting queue using the existing ListCommentReports and ListPostReports endpoints, like lemmy-ui does, to create your mod queue.

Unfortunately this doesn't work without grabbing all reports all at once. For example, imagine if you grabbed the first page of 20 reports. A client may group 4 reports to one post, and the user resolves that and approves the post. But then you get the next page of reports, and another report comes in for the same post you just approved. It's not a great experience.

Hopefully I explained that OK!

[aeharding]

Issue updated to specify unresolved counts to be added to posts/comments, not the entire report objects.

[dessalines]

We've added filters now, so ListPostReports has a post_id filter, but the problem is there's no way to know which posts or comments even have reports.

I'm thinking the best way to handle this, would be to add the report_count mentioned above to PostAggregates and CommentAggregates, and use SQL triggers on report creation to increment those fields. @dullbananas what do you think?

cc @SleeplessOne1917

[dullbananas]

I'm thinking the best way to handle this, would be to add the report_count mentioned above to PostAggregates and CommentAggregates, and use SQL triggers on report creation to increment those fields.

Good idea