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.
2 Likes
Oh, I see. I misunderstood what this is doing.
Well, even better.
2 Likes
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!
3 Likes
Just saw this plugin. Very cool.
1 Like
Thanks for the plugin @RGJ, it seems to fulfil my needed feature. 
Two issues I came across while testing it:
- 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. - 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 
1 Like
That is very true 
But issues of plugins and environment is out of my hand (otherwise would be⌠exciting 
)
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 
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.
2 Likes