New category permission : "Create and see"

That’s it :). It may sounds a little narrow, but this would be just for a specific part of the forum where the users only expect one group of “professional” users to answer the questions.

I could make use of this permission setting as well.

Would it be possible to incorporate this feature, it would be great!

I was about to make this topic. Would definitely use.

Would be useful for us as well.

In addition to what OP is asking for, more exactly what we want is:

New topics in FooCategory will only be visible to original poster, + moderators and above. That way users could also share sensitive details to have their problems solved, and we’d only make their threads visible (and answerable) to all if they opted i for that, upon or after topic creation.


@erlend_sh it sounds like what you want is a little different. If I understand correctly, the OP wants these topics to be e publicly visible, but to lock out most of the world from replying.

What you’re describing sounds like what we were hoping to do as well though.

The site’s custom forum software has categories like this for customer support and it’s super useful.


However, for them, anyone can see the list of topics, just not the content.


You have this in the Current version or a plugin?

I would love to have this as well for a gaming forum I’m in the process of setting up. I want to have a section where low level players can ask high level players questions. Similar to this.

1 Like

I came here to request the same thing or very similar.

My scenario is a board that is private with patients and doctors/health care professionals. The concept is a live Q&A session. The patients could submit questions (topics) to a queue (category), all members could see the questions and answers, but only the doctors could respond in the category. Ideally the topic creator could also reply to their own topic. This way doctors can see which topics have answers and other members could vote on the questions (topics) before the doctors come to answer, thus promoting the popular topics to the top. If the topic creator could reply in their own topic, then the patient and doctor could have a conversation, while allowing other members to read/see.

1 Like

As you’ve described this, a Q&A platform is a better fit (no surprise, since you called it a Q&A!). Q&A platforms do this very well, and the result is a knowledge base that can be searched and used forever, and users tend to be much more careful about topic titles and contents, because they are intentionally going to become an archive.


We’ve been thinking about using Discourse as a support forum solution for our product. We need a similar feature where TL0 (new) users should be able to post a topic into a “Private Support” category. This category should be visible to all users but topics posted into the category should only be visible to the original poster and “staff” (or some other blessed group).

Without this feature I don’t think we can use Discourse as a product support solution. Sometimes people want to request support but don’t want to do so in a public way. They could just send us an email but then that makes it difficult for a group of people who can respond to know what other support staff have said.

Group private messages could also solve this problem but:

  1. Trust Level 0 users can’t send PMs.
  2. There is no “send private message to group” action when viewing a group.

Sure, and as you can see that’s been discussed before. It’s a different use case though, it’s a bit more like private messaging than Q&A.

Yeah, a Q&A platform might be a better fit for our use case. It is just annoying to have two different systems for Q&A/Support and general User-to-User discussions. Nicer when one system can fit both models reasonably well and I think with only minor changes to Category permissions Discourse would do the trick.


I have a use case for this. I’m running a gaming forum (for a guild) and we’d like to have the ability to accept applications to join the guild.

  1. Applications need to be private. The public should see no applications.
  2. Applications need to be visible to the thread creator.
  3. Applications need to be able to be visible to a particular group (guild members or officers).

I’ve been digging around the permission code in the discourse backend but it’s still a touch tricky to get my head around. If anyone could give me some pointers that would definitely make things easier.

Edit: After playing around with this idea for a few hours, while I’d like to see it there appear to be a few serious roadblocks that make this concept pretty tricky to pull off as a plugin so I’m hesitant to continue unless this would be something that would be merged into discourse as a whole:

  1. There’s a very strong relationship between being able to see a category, and being able to see the topics in that category. This assumption is coded in several of the guardians.
  2. There aren’t really any extension points in the guardian code so I’d need to monkey patch several methods both in the category guardian and in the topic guardian.
  3. I’d need to add a new permission enum value (4) which would break a plugin if discourse ever decided to make their own extra permission, this could cause some “interesting” data errors.

While I’ve managed to get most of it working by just hacking the discourse code (I haven’t gotten it filtering the topics in the protected category) I don’t want to continue since deploying this code isn’t really something I could easily do.


I would like to slot this to a release @codinghorror its kind of critical for anyone migrating off zendesk


If this is low hanging fruit, go for it.

But if it’s already tricky and the support ticket use case us under serious exploration, I am not sure the category permission paradigm is the best place to start.

It may be worth exploring enhancements to the private messaging feature to enable these workflows.

The flexibility to add (or remove) additional recipients on either end was always something helpful for us when using any system for support tickets.

A few more thoughts here, but I could say more if that’s really the goal.

1 Like

Would really love to see this too. The simplified permissions model is usually a boon but for this one case.

We could kill off several other tools/services overnight if this were implemented, particularly if users had the ability to create threads in a particular category and only see the threads they’ve created.


I would like to see better group mentions and PMs.


Perhaps a search filter + minor change will give us a large amount of this request …

  • Allow users to easily create PMs to a group (without expansion hacks that are used with the @mention stuff) - never been a fan of the expansion hacks.

  • Allow for a search filter to:GROUP_NAME to see all PMs sent to a particular group in the full screen UI

Together I think this would cover the sentiment behind the original request.