Private Topics Plugin

Do you know does this work together ActiviyPub plugin?

I have not tested that. This plugin overrides the access and visibility checks so generally it works well with other plugins. I can imagine that the ActivityPub plugin hooks into places that (inadvertedly) bypass these checks though. The only way to find out is to test it.

That said, I don’t see a use case where private topics categories would be eligible for activitypub.


Oh, I see. I misunderstood what this is doing.

Well, even better.


Thank you for this awesome plugins, we were missing this since a long time.

We have tried to couple this with “email in” feature. It works fine for simple case, more complex cases don’t work very well:

  • If someone send a mail to 2 “private topics” categories email, it appears in only one (quite normal in the way discourse work, but not understandable for people using the email)
  • Same if the user send to several mails bind to groups and other to categories
  • if the user send to external emails and to the “private topic” category email, when we reply, others external mails doesn’t recieved the answer. (Groups messages support this, cause we can invite someone in the conversation)

Those issues are not specific to this plugin but a general downside of category topics vs group inboxes. This plugin does not aim to solve all of those.

1 Like

Fix: Discourse AI semantic search was able to bypass the protection. This has now been solved. If you’re using this plugin together with the Discourse AI plugin, make sure to update!


Just saw this plugin. Very cool.

1 Like

Thanks for the plugin @RGJ, it seems to fulfil my needed feature. :slight_smile: Two issues I came across while testing it:

  1. If I “open up” an existing category A (so far only accessible for group A) by activating within the security settings the “enable private topics” checkbox and adding rights for another group B to be able to post their private topics, it seems, that all existing topics by other users of group A can be viewed by members of group B. So it seems, that the private topic feature only works for topics created after enabling of the plugin, but not for existing topics, created before enabling the plugin. Can someone confirm this?
    My expected/wished working would be that also existing topics stay/get hidden for users of group B (as it works for new topics). Otherwise I’m not sure how to migrate.
  2. While testing, I noticed that after having created a topic by a user belonging to group A (owner of the category), that for a user of group B the counter New (1) in the category view was shown. As the topic was (correctly) hidden to the user, this notification by the counter seems to be a bug and might irritate users.

discourse 3.2.0.beta5-dev (cef6aca6e5)
plugin 1.5.3 (709df2c)

The plugin does not only affect topics created after enabling the plugin, it works for all topics in those categories.

I’m not sure what

means. If it’s about the group selector below the checkbox, then that’s not what that setting does.
Topics are visible for the topic starter and for users in the following groups
When you add group B there, you give all members of group B the power to view all topics. This is meant for for instance your support team.

If it’s not about that group selector then please describe your setup in more detail.

Sorry, I expressed myself badly.

I did not add group B there. I only added group B to the generic security settings to allow them to see the category and post topics.

More detailed setup description:
Category settings before enabling the plug-in:

  • Only group A has access to the category (view, reply, post).

Category settings after enabling the plug-in:

  • Adding access for group B to the category (view, reply, post)
  • Enabling Private Topics for this category
  • Add group A to Topics are visible for the topic starter and for users in the following groups: (actually, it was added already by default)

First of all, I have just pushed a fix for Ember5, but that should not have influenced the working of the plugin. To be 100% sure, please rebuild and configure the plugin from scratch.

I cannot reproduce this.

  • Set it up as you said, with user A in groupA and user B in groupB.
  • UserA made a post
  • set up the plugin
  • User B made a post
  • User A made another post

Admin view

User A sees

User B sees

So this behaves as expected.

Also, this is very strange, there is no default group addition there.

1 Like

Thanks for your fast feedback & testing, @RGJ ! And sorry for the late reply, some other tasks kept me away from the issue for some days. I updated the plug-in and retested with another category. I cannot reproduce it myself now, so seems to work as expected. Only topics started by an admin are shown in the category (probably intentionally and sensible), I might have mixed that up in my first test. Sorry for the noise!

The issue with the “new”-counter for new topics seems to persist: The user in a group only allowed to see their own threads has a “new”-counter, but cannot see new threads, if a user of the “support”-group (allowed to see all topics) posts a new topic. See screenshot below: “Neu (5)” for user without rights

View for support-user with rights:

1 Like

Correct, this is controlled by the setting private topics permitted groups “Always show topics started by a member of these groups”

Yes, it’s a known issue. PR’s or pointers are welcome.

1 Like

One question, even I may know the answer.

What happends if the plugin must be disabled, because of some conflicts etc. Will then every topic and post be visible to everyone or will that category be restricted to everyone?

Because the first option is something that is for me totally no-no, too much sensitive data. But if the second one… with that I can live with.

When you disable the plugin, all topics in the category will be visible to everyone.

If you want to avoid that you should modify the category permissions to be more strict, before disabling the plugin.

1 Like

As I excepted. So, there is one huge risk: human error. If I have to disable it I should remember in that chaos adjust group restrictions too. That is really big questionmark actually.

Avoid the chaos and you’ll be fine :wink:

1 Like

That is very true :rofl: But issues of plugins and environment is out of my hand (otherwise would be… exciting :man_facepalming:)

Just playing with idea… if there would be some security measurement, like companion component that has one and only one job: watch status of the plugin and inform right away admin(s) that the category is visible to the world.

I’m small player, but I just wondering are those company based forums, that are using this, and quite often have more that one admin, fully aware of this risk :thinking:

1 Like

Without knowing much about the possibilities, thus maybe just an irrelevant thought, how to mitigate the risk: Before/during disabling the plug-in, show a dialogue to the user, reminding them of the consequences of disabling the plug-in and to double check the category security settings.

Just my 2ct: In general, I would assume that the issue is rather minor, as I would assume that people not blindly disable a plug-in they need, but will spend some thoughts about how to fulfil their requirements if they need to disable the plug-in…

The most common reason is forum is down. And I don’t know too many admin who keeps thinking when they know what is the cause and the fix is disabling a plugin. I like Category Lockdown but because its broken I took it down in a second. At that point I now should remember what are limitations of one spesific plugin that has behaved nicely a long time.

This is same issue than with backups. We all know darn important backupping is. But if it is depending on manual work and remembering… then there is no backups or thise are really old.

The human factor is the biggest risk ever.

Anyway. The plugin itself is wonderful but I have to think a little bit pros and cons. I’m under different regulations and exposing that data can be costly in more than just one manner.