I don’t disagree. But once the “specific people” grows to a group of several hundred, you kind of want some of the nice features that Discourse provides for browsing public topics. So maybe the differentiating feature here is the size of the receiving group?
1 Like
Hi again, Geoff! Hope all is well.
I’m in the same boat of wanting to be able to see PMs in the Latest/Top/New pages (for precisely the same use case), but separately from that, if I’m understanding you correctly, this part (toggling the public/private nature of an existing topic) seems to exist already.
From the topic-level admin actions wrench icon in the top-right, you can click “Make Personal Message” (or “Make Public Topic” if it’s already a PM). Switching an existing topic to a PM seems to retain access for everyone who posted to the topic, and then you can add the staff group as well. It does move the thread out of the topic list and into the messages section, though.
Yeah… hence the problem.
What’d I’d love is something like the hidden feature but that would leave the message visible to all staff with a certain trust level. That may be doable…
Would it work to manually set, e.g., trust_level_3 so that anyone can send PMs to it (under Groups → trust_level_3 → Manage → Interactions)?
Then it seems like you could manually add the trust_level_3 group as a participant after you convert a public topic to a PM.
That may not be quite what you’re looking for (and I’m not sure I understand enough of the inner workings to say for sure that it would work), but it might maybe serve some of the purpose.
I’m another late-comer to the discussion, with an almost identical use case to @Geoffrey_Challen (running a large class and hoping to use Discourse to manage Q&A and discussion).
I’m not personally concerned with the mass of e-mails (I set to mailing list mode anyway), I do think it would be a big quality-of-life improvement to be able to answer the question of “What are all of the threads I might need to read / respond to?” from one place, regardless of whether those posts were public or were sent to the staff group (or maybe even just direct to me).
The “create” permission as originally discussed would be one way of handling that. Another would be to allow certain groups’ PMs to render as pseudo-categories in the topic list pages (New, Top, etc). Given the similarity of the structure of PMs vs public topics in the database, it seems like that might maybe be possible (though there is a level of added complexity there for sure).
A different alternative that might help out in a similar way but not require such large changes would be if the search box had a way to search across all topics and PMs (right now, afaict, I can search for one or the other but not both), and ideally to refine things by specific PM recipient groups. For example, I’f like to be able to say: “show me all open threads that were either public topics or PMs to the staff group.”
If modifying the search feature in that way is possible, that seems like it would provide a lot of the functionality I was hoping for, and do so in a way that wouldn’t require changes except to search. But maybe there are complications there, too, that I’m not thinking of.
I do think that might be part of the issue here. Maybe to do also with the amount of traffic of the group PMs vs public posts? Our use cases involve a lot of interaction in both puvlic topics and group PMs (and a large number of threads in both), whereas for a lot of other use cases, private messages to staff might be more rare, and maybe that has an impact on the way people want to interact with those things?
OK… after a few hours of hacking this afternoon I have a prototype of the Create only permission (in the cs125 branch). Very minimally tested, but here’s what seems to work:
- Categories can be assigned a Create permission
- Users with that permission can create topics in the category and reply to their own topics
- They can still see topics created by other users, but an attempt to access them returns a “This page is private or …” error.
- Admins can see and respond to all posts.
- I have no idea whether other category permissions are still working, but don’t know why they wouldn’t be…
Assuming this is actually working and not just my wishful thinking, I’d really like to get #3 sorted out so that the UI is less confusing to students. But that’s where I got lost—although maybe because it’s been a pretty long day. @sam: any help here, or are you going to disavow us now that we are this far off the reservation 
. Essentially I want to be able to filter the topic list for a category (and really all topic lists) to exclude topics in categories where the user only has Create permissions unless the user created that topic.
PS: this branch also extends whisper permissions to users with trust level >= 3. Others may or may not want that change, but it’s useful for us, since moderator privileges are too much horsepower for most of my course staff but whispering is really useful when working together to help students.
@sam: another quick question. Is there any prayer of doing either of these things via a plugin?
This is almost exactly how the restricted replies plugin works
The only thing is doesn’t handle is (3). That will be extremely tricky to implement, because of all the reasons listed above.
3 Likes
Correct me if I’m wrong, but it looks like your plugin doesn’t prevent people from seeing posts that they didn’t create. That’s essential to our use case: students posting questions to our course forum that may contain code and or other parts of their solution. So we not only need staff to be the only people who can reply, but also the only people who can view. Restricted replies says it operates like a “Create / Reply (to self) / See” permission. We need essentially “Create / Reply (to self)” but not see.
That said, it’s really encouraging that you can do this in a plugin. Would it be possible to also restrict viewing as well to support our use case?
WRT #3: I was wondering if it would be easier to do this on the client. Currently with our changes students can’t enter these topics anyway, so even if we could just hide them in the UI that would be sufficient.
Yes, you’re correct. That’s why I said it doesn’t achieve (3)
What if a user is watching the category, and receives notifications for the secret topic? What about mailing list mode? What about user ‘activity’ pages? What about ‘top’ topics? What about ‘new’ topics? What about search? And probably many more questions… This is a massive undertaking, and I would not recommend it.
Group PMs are designed for exactly for your use case. We handle all our support email through Group PMs here on Meta, and it works great! If there are specific usability issues you are having with group inboxes, then I think your time would be better spent exploring improvements there.
3 Likes
I don’t disagree. But we’re here because we’ve tried Group PMs and they aren’t working that well, given that we have ~200 people on the receiving end of the message.
I touched on this in my reply to Sam, but group messaging doesn’t seem like it works that well once the recipient list gets really large, and the probability that I’m going to respond to each individual message drops. Put another way: if group messaging worked that well, people would still be using large open email lists rather than great tools like Discourse.
We’ll probably continue with group messaging rather than risk the breakage that you are right to point out might result from an attempt to modify the category permissions. But it’s not really that useful to be told “group messaging works great!” when your experience is that it does not, in fact, work great 
2 Likes
Sure, there will always be differences in how things are used in different communities. I meant that it would be interesting to explore what developments would be required so that you could use PMs successfully. I think changes there are far more achievable than re-implementing PM features in regular categories.
What specific issues are you seeing with group PMs? To give an example, maybe it’s an overload of notifications? That’s one of the issues we had originally, and you can now configure the tracking level for each group inbox.
6 Likes
Yes, that was a really helpful addition! Thanks.
If you look at some of the discussion above I think you’ll see a few problems with the PM system. Mainly, there is just a different workflow for working with messages, which creates an artificial separation between topics that I want to handle similarly. (Hence the attempt to bolt this on to the existing category permission model.)
There’s a list here, but it really just boils down to making message groups look as much like categories as possible. Having them on the homepage, and in the latest topic view, and having them look the same when browsing, having the same searching and filtering options (without having to remember that it’s a message), etc. Unfortunately my sense is that this would require as much if not more breakage as additional category permissions. But perhaps not?
@david: sorry to jump in to the conversation, but I have a very similar use case to @Geoffrey_Challen, and while I certainly can’t speak for him, I think one concrete thing that would help me along these lines would be to have the option to run a single search query in a way that matches both public topics and private messages (right now it seems I can search for public topics or private messages but not both, unless I’m missing something).
I understand that some of the other changes suggested here (“Create” permission, allowing PMs to display in the regular topic lists, etc) involve sweeping and complicated changes, but maybe a change to search to allow searching across all topics (public or PM) would be more practical and more local, while still providing the ability to get some semblance of a unified view of those things via search
For me, I don’t think overriding the default interface is important, but it would be fantastic if I had some way to quickly answer the question of “What are all of the threads I might need to respond to right now?” regardless of whether they were public or private, and to refine that based on tags, etc.
In the meantime, I wrote a little script that I can use to grab this kind of unified list directly from the Postgres database, or I can run two separate queries through the search dialog for each thing I want to search (one for public and one for private), but both of those are kind of painful…
2 Likes
Sounds like a great idea to me - I would use that. Best thing would be to create a new feature topic, so we don’t lose track of the idea in this topic.
Edit: done here
4 Likes
I am really struggling to understand the aversion to allowing this type of permission structure after it has been discussed since 2015. I can certainly see the appeal of the OP along with aversions to the private messaging as an alternative. Slightly more granular permissions would be a massive game-changer for Discourse - it would open a lot of doors to more creative uses in communities.
The effects of granular permissions are… well documented. I still have nightmares thinking about the mess vbulletin made of category permissions, for this exact reason.
The point is that if you want users to be able to create topics and only see the topics that they have created then this functionality already exists in PMs. Combined with group mailboxes it already replicates the desired behavior.
1 Like
I don’t personally have any experience with vbulletin or other forum software. My background in community-based platforms comes from Discord where community creators have more control with permissions. I have also seen permission systems successfully implemented on plenty of other systems that allow for more control. I don’t think anyone is asking for 500 toggle-buttons in this scenario, but instead the ability to assign Create, See, Reply permissions independent of each other.
The desired behavior is for the user to open a category, click “New Topic”, type their content, and their post only be visible to them and whoever has the “see” permission. PMs are far more cumbersome to navigate for the user than what I have described above - they require more user initiative and the function is more buried in the UI.
A simpler solution to the issue is to allow topic creation by email, however this has a drawback as well. It does not promote participation in the community directly and requires the user to use a third-party system to accomplish the goal.
Direct messages and category permissions are two separate topics and not really what the OP had requested nor are they what a number of people that will come after will be looking for.