Private Topics Plugin

[RGJ (Richard - Communiteq)]

	Summary	Private Topics Enables private topics in a regular category
	Repository Link	GitHub - communiteq/discourse-private-topics
	Install Guide	How to install plugins in Discourse

Features

This plugin allows you to add an extra security setting to categories so that users can only access their own topics. You can also designate one or more groups that can see all topics in the category. This is typically used for providing private support within a public community.

Rationale

We were looking for a more integrated way of being able to provide support for Communiteq’s clients without having to create a few thousand categories. We also wanted to stay away from Group Inboxes because they feel too much bolted on and by default you get a “new PM” bubble every time someone posts something in any group inbox.

I previously wrote about this idea here.

@RGJ

What if there was some kind of ‘drop box’ category where people can start a topic and interact with support staff (basically: a group), where only they and members of that group can see the topic?

That would be a golden bullet for this use case. We would have a clearly defined “support” category where every user can see their (and only their) support tickets. Everything is in a single place and you can use tagging and everything.

Configuration

After enabling the plugin, go to the security settings for your category.

Settings

There are a few global site settings as well:

• private topics permitted groups : designates groups whose members’ posts are consistently accessible. You can use this so posts from staff or support staff are not subject to being inaccessible, even when they’re in a private category. Posts from the default system user are also always being shown. You should make sure that the category introductory posts are either from the default system user or from a user in this group, if you want these to be shown.

• private topics admin sees all: when enabled, admin users can access all topics, even when they’re in a private category. Disable this if you want to hide confidential data from accidental glances.

Caveats

The plugin filters topics from topic lists, post stream, search, user summary, user activity, the not found page, follow notifications and raw.

Topics are included in badges, but badges are not granted for non-public categories, so you should remove everyone from the category security groups and add trust_level_1 instead.

This plugin is brand new and has not been tested extensively yet.
Possible “leaks” are:

• message bus (sometimes a “there is one new or updated topic” flashes and then disappears)

Todo / Roadmap

• have a category banner that explains that it’s safe to post more or less confidential things in the category.

[Stephen]

Really nice work Richard!

[Lilly]

woah this is awesome. great work!

[Stephen]

One small observation - it appears that even admins can’t see these responses if staff or admins aren’t specified in the groups. Is this intentional?

I just created two test categories, one where admin was specified in the groups, the other where it wasn’t. Moving the topic from one category to the other means I lost visibility on said topic. The topic name is leaked by the Delete Category button though, which shows and names the topic still present which blocks deletion.

[RGJ (Richard - Communiteq)]

@Stephen

One small observation - it appears that even admins can’t see these responses if staff or admins aren’t specified in the groups. Is this intentional?

Yes, I did intentionally put not any effort in treating admin in any special way (in the spirit of this and this), since it’s trivial to add the group and it’s really helpful in testing when admin is subject to the regular security rules.

On the other hand I did not put any effort into closing any “leaks” for admin users either, especially because it could cause problems when administering the forum.

It’s a good remark though and I’ll make it explicit in the start post of this topic.

[Stephen]

Any scope to list topics to admins in the category view, even if the name is obscured?

[RGJ (Richard - Communiteq)]

Can you please elaborate? I’m not sure if I understand what you mean.

[Stephen]

It’s rather unprecedented for content to be present which admins can’t see by default.

If you don’t want to display those topics to admins unless their group is explicitly named, can we at least include something in the topic view letting them know that there are private topics present which they won’t be able to see? It could be anything from showing the topic names in the topic listing but preventing the topics themselves from being opened (the latter is the case now, links just don’t work), to including a notice at the top of a category to tell the admin that private topics are enabled, but they don’t currently have permissions to view them.

[RGJ (Richard - Communiteq)]

I understand, thanks for the explanation.

I will add a site setting early next week that skips all the filters for admin users.

[RGJ (Richard - Communiteq)]

I have added a private topics permitted groups setting to designate groups whose members’ posts are consistently visible. You can use this so posts from staff or support staff are not subject to being inaccessible, even when they’re in a private category. Posts from the default system user are also always being shown. You should make sure that the category introductory posts are either from the default system user or from a user in this group.

I have also made the functionality that admins can see everything the default. To revert to the old behavior, you can turn off private topics admin sees all. @stephen

[Festinger]

Thanks a lot for this plugin @RGJ - it will be very useful to our community.

If I understood it correctly; users are safe to create topics in this category with confidential information as well?

[RGJ (Richard - Communiteq)]

@Festinger

users are safe to create topics in this category with confidential information as well?

It is designed to deliver the same level of confidentiality as a group inbox, i.e. only the topic author and a defined group will be able to access the topics under its regime, plus admins and anyone who has (gained) access to the database.

Please note that the plugin is 4 days old and is still labeled ‘beta’ so it’s not extensively field tested yet.

Maybe I should put a bounty on it so we can get it to battle-tested level more quickly: whoever finds a way to bypass it and can access a topic as an unauthorized regular user gets 2 months of free Communiteq hosting. One month for partial leakage like a topic title.

[Stephen]

The only thing I’ve seen so far (and it’s very mild) is on the user profile summary, where you can see the user has created a topic in one of those categories via Top Categories. Neither link (to category or count) exposes the topics though.

Edit: I did find one actually, but it’s through an official plugin rather than core. discourse-follow will leak the title and URL to private topics.

[RGJ (Richard - Communiteq)]

@Stephen

I did find one actually, but it’s through an official plugin rather than core. discourse-follow will leak the title and URL to private topics.

Thank you !!!
This has now been taken care of.

[Stephen]

I found two more title/URL leaks, one is related to the other.

Steps were:

• Topic is created by user 1 in a different category and interacted with by user 2, which sets that topic as watched.
• Topic is moved to private topics category
• Topic sees further activity which triggers notification of topic to user 2 despite them being unable to access it. (leak a, minor)
• Notification leads to usual " Oops! That page doesn’t exist or is private." showing several protected topic titles in the Recent block to user 2. (leak b, slightly more severe)

[RGJ (Richard - Communiteq)]

Thank you @Stephen, you rock!!!

I’ve fixed the recent topics on the not found page. It will now exclude all topics in private categories.

[anilguven]

Thank you @RGJ

The Discourse was indeed in dire need of this. The Create/Reply feature, inherent in most forum platforms, was truly requisite in its integral framework. I extend my gratitude for your diligent efforts in this matter.

[a1xex (Alex)]

Hey,

I was trying this plugin out for my community, and when me and a few other members tried to test it, it didn’t seem to work as intended. The posts created by normal members show for everyone else and not only the private groups selected. Is this plugin possibly not up to date, or have I done something wrong?

[RGJ (Richard - Communiteq)]

It seems broken on latest indeed. Please bear with me while I fix this.

[RGJ (Richard - Communiteq)]

It’s fixed, just pull a new version and you’re good.

Thank you for reporting!

Apparently this

<Input
   @type="checkbox"
   @checked={{this.args.outletArgs.category.custom_fields.private_topics_enabled}}
 />

now fills the field with t while it used to be true.