Problem is that the most common way of disabling a plugin is by simply removing it and then rebuilding. So from within Discourse, the plugin just “disappears” at once.
How about a theme component that, when the setting private_topics_enabled is not found, or is false, displays a warning banner and uses CSS to blank out some specific categories to mitigate the impact?
I see. Would a warning-message to stdout/stderr improve the situation in this case? (Might not be enough on it’s own, but better than nothing.)
Same problem: at the moment the plugin is gone, there is nothing that would be able to output that message.
Sounds actually quite good. I think.
If it were possible to implement this plugin in a way that it allows additional groups of people to post and see their own messages, disabling of the plugin would be no risk.
I can’t tell where the change in core occurred, but I believe some change pre 57df0d526e has allowed for users to see topic titles on the home page, which is a change in behavior, as far as I recall.
I have tested this on tests-passed as of earlier today (4c7d58a, after your commit) and I am unable to reproduce this.
Do you realize that admins can see everything (per the “Topics are visible for the topic starter and for users in the following groups:” category setting and the private topics admin sees all plugin setting) and everyone can see admin posts (per the private topics permitted groups plugin setting) ?
Hi Richard, yep! I’m testing this in an incognito tab. I’ve got quite a lot of other plugins enabled - so it might be something else interfering, so I’ll get back to you after disabling some - sorry it’s not as clear cut as I initially thought.
I’ve been testing this on my 93-plugin test site so this makes me curious 
That said, I did also test this with no user logged in, BUT it should be good to know that anonymous pages are being cached on various levels, so if you enable the private topics plugin, you might still be seeing existing topics for a few minutes.
Unfortunately, I wasn’t all that successful narrowing down any conflicts caused by plugins. I’m sure my measly 15 plugins are likely all covered by your test site’s 91, however! 
These were both taken in incognito mode, and I can reproduce it with a user without sufficient privileges to view the contents of the private topic categories, too. I’ve checked my category settings for Private Topics, and the global site settings, and those don’t seem to be in error, either.
If there’s any additional debug you can think of, or steps to check, I’d greatly appreciate it - but thank you for your support on this regardless - this plugin really has been great for our needs! 
Ah, that category setting is what causes it. I can repro. To be continued.
Thank you for reporting!
I have pushed a fix for the above issue.
If this plugin is used together with your Discourse Private Replies Plugin, one gets infinite recursion in digests, since both plugins use alias_method :original_for_digest, :for_digest.
Thank you for reporting this, I have resolved the conflict.
Can users send access requests to the topic creator?
Similar to sharing files/folders in Google Drive, the Topic Creator who receives the topic access request notification will Accept or deny to view the topic content, notified via Email/Discourse notification.
This means that the Topic Title is now public but users must click on the Request access button.
Thank you!
This could be done by having users request access to a group, and have the group be able to access the topics.
