The reason I personally think it would function better as a permission is because the user isn’t stuck with the burden of deciding who the support topic goes to.
Unless there will be some way to force PMs in a category to go to a certain destination…
I don’t think PMs should support categories. Categories in Discourse are becoming specialised and specific: They can have special plugins enabled (Solved, Prefilled) and they can have special permissions (“only TL2+ allowed”, “private”).
Should a PM inherit some of the unique properties of its assigned category?
If yes, how.
If no, I guess you’d want to create unique categories specifically intended for PMs then, which means you’re not really using Categories at all, you’re inventing yet another new taxonomy for Discourse.
It seems much more reasonable to support tags instead.
But if you’re going that far, couldn’t you just as well implement the create/create&see (+ other) permissions instead, and re-implement PMs based off of that?
Some other limitations of PMs:
You can’t create a topic by e-mail (like you can with ZenDesk et.al.)
You can’t assign tags
You can’t (easily) move it to a public category (say, it’s a great FAQ item, and the customer gives you permission to share it)
I believe it would be much harder for newly appointed Mods to get access to old topics, which can be an invaluable resource.
PMs could be a category. Just one. A special, default one, part of the package like Lounge and Meta.
It could use the same principles as the approach suggested for topic archives:
So when you PM someone, your topic ends up in this special “PM Category” that isn’t visible in the normal drop-downs, not even to Admins. So besides the fact that it’s essentially an unlisted topic shared with whichever participants have been invited, you can tag it, wikify it etc., just like you could with any other topic.
(sorry if this seems off-topic, but I think it’s very much on-topic, since we’re discussing whether OP’s suggestion is better off dismissed in favor of PMs, which I’m arguing is not the right way to go).
IMHO this would be a bad thing.
True, it would be hoped that Admins wouldn’t abuse the ability and snoop, but they should be able to check on any message that was reported as being a problem.
PMs cannot be disabled between users and staff. So when you disable PMs you are effectively disabling it only for users.
Let me make sure the copy is clear on this because you bring up a good point. I changed it thusly, adding the bit in bold:
Allow trust level 1 (configurable via min trust level to send messages) users to create messages and reply to messages. Note that staff can always send messages no matter what.
oh ok. Any chance to implement user initiated staff PMs ? This will help in all communities who disable PMs but still provide a chance to reach the staff through the UI.
Thanks for the hint. It would be really useful if we can link the welcome message to a button / link in the home page for eg “Contact”…otherwise it is very unintuitive for an end user to try this…simply because the welcome message is hidden in the messages page.
Feel free to create a public help topic about this and pin it or make it a banner if it is a frequently asked question on your site.
If you read the welcome PM, it does explain this at the bottom, but… That requires reading and processing words on a web page, which users are unlikely to do.
I think you are ferociously paddling upstream here.
If you have explicitly disabled PMs, there is usually another prominent way to contact staff at the site in case of issues. For example see your built in about page, http://discourse.example.com/about
And TL1 users can still flag anything with a custom reason, which is a de facto PM to staff.