Skip to content

feat: ignore private posts/discussions for filtering - #69

Open
luceos wants to merge 2 commits into
FriendsOfFlarum:masterfrom
blomstra:master
Open

feat: ignore private posts/discussions for filtering#69
luceos wants to merge 2 commits into
FriendsOfFlarum:masterfrom
blomstra:master

Conversation

@luceos

@luceos luceos commented Jul 21, 2026

Copy link
Copy Markdown

Sometimes you want to exclude that private discussions are filtered for bad words. Byobu for instance. To prevent these private chats from being opened up, and details send through email, to staff, this feature offers to ignore any private discussion/post.

@luceos
luceos requested a review from a team as a code owner July 21, 2026 11:21

@DavideIadeluca DavideIadeluca left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice to have addition! Though I have one question below about some potential unintended side effects

Comment on lines +53 to +57
if((bool) $this->settings->get('fof-filter.ignorePrivatePosts')
&& ($post->is_private || $post->discussion->is_private)) {
return;
}

@DavideIadeluca DavideIadeluca Jul 21, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When a user starts a new discussion in a tag the user doesn't have permissions to start a discussion without approval but is otherwise public, may in this case those posts not go thru this listener unexpectedly when the feature toggle is enabled? From what I recall unapproved posts and discussions both have is_private set to true

Looking at the logic in flarum/approvals it doesn't appear like that approving a post triggers the Post Saving Event again

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point. One could debate whether an unapproved discussion might skip filtering anyway because it will need to be reviewed. But then it would completely render the ability to delete immediately defunct.

So instead of just using is_private, a test against recipientUsers or recipientGroups could be suitable. Not sure that's too opinionated for this extension though 🤔
Or alternatively make the condition as proposed but more complicated by ruling out some scenario's like approval?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd opt with your second option of making the condition more complicated and also check the approval state when flarum/approvals is enabled. Can you make this change and along side patch the formatting to satisfy StyleCI? thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants