Basically, we’re hoping to set up groups to manage posting permissions within a topic, but we still want every user and unregistered guests to be able to read what is posted.
Any way to make this work?
1 Like
I get that you can do it for a category, but we’re hoping to not have to make an entire new category given all of these topics are already neatly sorted into categories and subcategories.
We’re really hoping for the ability to restrict replies (and likes, actually) on a per-topic basis.
You can’t out of the box AFAIK. But I would like to be wrong now.
You might want to archive those topics.
Not sure how that still allows users of a certain group to post there…
1 Like
Ah, sorry @orangeandblack5, I wasn’t considering your original question, just replying to this part:
Let’s start over…
In Discourse we set group permissions at the category level, not the post level, so I do not believe there is a way to do as you ask.
I’m curious: why do you not want anyone who can read the topics not be able to like them? I thought of archiving because maybe you wanted to “freeze” them, but it sounds like you want some folks to have the like ability and others to not have it. I love hearing how people use Discourse in their communities! 
For us, the posting bit is far more important than the liking bit, but in general we use Discourse to run various types of games and discussions online that people have to sign up to participate in, and it’s against the rules to post in a game you are not actually playing, but we have no software enforcement of that and so sometimes new users get confused and end up disrupting things on accident when they should instead be signing up for an upcoming topic.
Some way to allow everyone to read all of the topics, but prevent people not signed up for a particular topic from posting in it would be awesome!
1 Like
I also think the only way to achieve this without custom code is adding a dedicated sub-category for each game or discussion that you want to restrict. This sounds cumbersome, but as you already have to set up a dedicated group each time it’s actually not that much more of a manual effort. In any case, the user experience will be clean with a setup like this:
- category : games
permission: everyone read - sub-category: game-A
permission: only game-A group reply
So topics from game-A will be visible for everyone, but anyone who isn’t a member of the game-A group and opens the topic won’t be able to reply.
If you want a very clean interface and it aligns with your architecture you could even hide the relevant sub-category badges from the interface with css. So the sub-categories are purely about access rights and not about navigation.
3 Likes
The issue with that is that we already use sub-categories to sort things.
We’ll consider it at least, but it’s really not ideal because we’d need to cut out an entire layer of sorting/organization and that could make the site way harder to navigate, especially for new users
1 Like
I suspect that you should use tags to do some of that organisation. See It’s Time We Talked About Tags.
There isn’t going to be an easy way to get per topic permissions.
1 Like
I wonder if there is a way to provide Page Publishing for PMs?
I don’t believe so. But you could publish them in a category that people could write to and then unlist them.
This is separate from the OP’s use case, but I admin a forum with one anonymous-only category where users can post about professional issues without exposing their usernames to everyone else (although they know the admins can find out who posted what if anyone misbehaves). It would be great to be able to restrict likes to only anon users too.
3 Likes
I have this same situation: we use Discourse as part of our custom LMS, and we wanted to sometimes limit access to a topic in a course to certain cohorts in the course.
So the only way to do that (as explained above) is to create a category for the course and then a subcategory for every cohort that needs to limit access…then copy each topic into each subcategory, which is kind of a drag, including needing to have models on our side that reflect this setup and code to keep things in-sync.
It would be sooo much more awesome if we could limit posts in each topic to groups.
Does each person need to reach the responses of all other cohorts?
If I were setting this up, I’d put the materials in a category that did not allow responses, just as reference material.
Then, I would send a group PM linking to the material, and holding the discussion there.
This way you just organize cohorts into groups, and can reuse the materials easily.
That’s how PMs work! 
But not for public topics.
2 Likes
@maiki Wooooah. I didn’t know about that. Thanks for sharing!!!
However, with the current strategy, it’s kind of set and forget. When a course is authored we can create the topic and subcategory for the DEFAULT cohort and then populate the topics we want. If a new cohort is added we create a new group and subcategory, and copy the topics.
Then we can forget about it and just handle activity notices via the callback.
With the approach you described, would it be more manual work? “Send a group PM” sounds like an activity that’s happening during the lifetime of a course. If a new student enrolls in an existing course and is put in a certain cohort, we can add them to the correct group in Discourse and they then have access to the existing subcategory (for that cohort) and the copy it has of all topics. In this case, would they automatically be added to an existing “group PM” so no diff in workflow?
Would the UI appear the same? Currently we just have the topic and then all the posts (for a particular cohort, if necessary) under them, per the ‘usual’ Discourse UI.
I must say I hate having to do the subcategories and copies of all topics whenever a new cohort is created on our side, and having to manage that, so this direct PM sounds intriguing. But I have this apprehension using a “private message” to do everything a category + topics can do is somewhere missing something.
1 Like
I can’t really imagine what that looks like for the users.
I just know that I often link to topic, or use Templates to reuse the content in PMs when I’m working with reusable content.
If you want to expand a bit on what you are doing, with an example topics and replies from students, so we can see what the cohort experience is, I’d be glad to ideate how to accomplish it using PMs.
1 Like
What I did was have a read-only category with the assignments and had students reply-as-linked-topic when they “answered” the assignment by posting in the class category. I’m not sure how easy it is to find reply-as-linked-topic on a read-only post these days.
1 Like
Thanks @pfaffman and @maiki for your thoughts. The way we’ve integrated the topics is to use the API to pull the most recent posts for a topic and show directly in the relevant course unit page in our LMS:
Then when you click “Join the discussion” it takes you to the topic in the category for the course and the subcategory for your cohort in the course, thereby restricting you to only comments from your cohort peers:
What’s a little wonky is this architecture leaks into the user interface, such as in this header:
and the nav…
This forces the student understand why there’s a top level category and then one subcategory level for the “Course Topics” (that’s the one for their cohort), and another for “General Discussion” (that’s the one for all cohorts in a course) … and if they click around they might get a bit lost.
Sometimes cohorts are more of an admin grouping mechanism not something the student cares about, so that can make this cat/subcat thing a bit more confusing. “Why isn’t there just one category for all the topics in the course?”
Plus as I mentioned before this setup means we need to duplicate all topics anytime a cohort is created, delete that subset when a cohort is deleted, or update every subcategory when a topic is created/updated/deleted.