I would like to have your opinion about a new permission for categories.
I’m building a support platform using Discourse in which users can ask questions and “professional” users can answer.
I would like to create a category in which standard users can ask questions but can only be answered by “professional” users. Standard users can see the questions and answers of others but can only create their own topics or answer their own topics.
Currently we have “Create, answer, see”, “Answer, see” and “See”, this permission would be something like “Create and see or answer own topic”.
What do you think of this feature? Do you think it would be easy to implement?
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.
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.
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.
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.
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:
Trust Level 0 users can’t send PMs.
There is no “send private message to group” action when viewing a group.
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.
Applications need to be private. The public should see no applications.
Applications need to be visible to the thread creator.
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:
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.
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.
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.
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.
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.