feat(forums): hide posts from blocked users

[wescopeland]

Resolves #5165.

This PR brings more intelligence to the user blocking feature to the forum. To mitigate scope, comments are unaffected, but should also be encompassed by this change in a subsequent PR.

Given User A has blocked User B, they will no longer see User B's forum posts. They will instead see a marker specifying that something has been hidden, but nothing else. The codebase considers these hidden posts to be "masked". If User A is a moderator, they see a "Show post" button on the row, allowing them to see the post content.

Behavior changes can be observed on five surfaces: the forum topic page, the forum index, the recent posts page, the home page recent posts component, and the forum sidebar.

Blocking a team account does not mask their posts anywhere. If User B opens a topic, User A will not see their topic anywhere on the site unless they land sideways on the topic's page via a direct URL.

Unblocked users may quote content from a blocked user's posts. This is a known gap, and we make no effort to conceal this.

[greptile-apps]

Greptile Summary

Masks blocked users’ forum posts across topic and recent-activity surfaces.

• Adds viewer-specific masking and cache invalidation.
• Adds hidden-post UI with moderator reveal.
• Filters blocked authors from forum listings and feeds.

Confidence Score: 4/5

The PR is not safe to merge until hidden replies stop controlling forum ordering.

Forum topics are ordered and paginated by blocked activity before visible timestamps are substituted.

Files Needing Attention: app/Helpers/database/forum.php

Comments Outside Diff (1)

1. app/Helpers/database/forum.php, line 89-91 (link)

   Hidden replies control topic ordering

   When a blocked user writes the newest reply, topics are ordered and paginated by that hidden activity before its timestamp is replaced, displacing visible topics across pages.

   Knowledge Base Used: Community Module

   Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

_{Reviews (3): Last reviewed commit: "Merge branch 'master' into forum-blocked..." | Re-trigger Greptile}

[wescopeland]

When a blocked user writes the newest reply, these clauses order and paginate by that hidden activity before its timestamp is replaced, displacing genuinely recent topics across pages.

My sense is this is overstated at best. A topic bumped by a masked reply will keep its bumped position, and the displayed latest comment is going to show an older date. The sort may look slightly out of order for that person, but this is just a cosmetic inconsistency. Worse, if we resort stuff, I'm pretty sure that could truly desync pagination. I don't think this is a P1, and I think the trade-off we're intentionally making here is measured.

[Chew]

I would personally argue that a "Show post" button should always show. Especially since you do not know who sent the post. This behavior matches other platforms (e.g. Twitter, Discord), where you just see "You blocked this person" and still have a way to show it. Though, this behavior is only really necessary on threads and not anywhere else.

[wescopeland]

I sense that will be contentious. We have users specifically asking us not to have that button because psychologically they'll always click through it. I want to see what kind of feedback we get by not including the button. It's a lot easier to add it later than remove it.

[wescopeland]

@greptile-apps

The PR is not safe to merge while hidden replies still control forum-topic ordering.

Forum topics are ordered and paginated using blocked users’ latest replies before displayed metadata is replaced, so hidden activity can displace visibly newer topics.

You likely missed my response to this feedback item:

My sense is this is overstated at best. A topic bumped by a masked reply will keep its bumped position, and the displayed latest comment is going to show an older date. The sort may look slightly out of order for that person, but this is just a cosmetic inconsistency. Worse, if we resort stuff, I'm pretty sure that could truly desync pagination. I don't think this is a P1, and I think the trade-off we're intentionally making here is measured.

[greptile-apps]

Fair point — you've already addressed this. The cosmetic sort inconsistency is a real but minor trade-off, and you're right that application-level resorting would risk genuine pagination desyncs, which is a worse outcome. Accepting the current behavior as an intentional, measured decision makes sense here.