Create/See and Create Permissions (again)

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…

This also ties into sending PMs to groups which we want to improve / allow at some point.

2 Likes

Maybe with better group tagging too (@someRandomGroup no longer expands to all group members)? :wink:

2 Likes

Yes exactly that! So maybe we can start by supporting categories on PMs somehow…

1 Like

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.

Here’s a random idea:

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.

It was a bit unclear, but I was piggybacking off of the archives suggestion:

a special category that doesn’t show even in staff lists (but retrievable through admin panel somehow)

In other words, I agree; PMs should still be accessible to Admins like they are now, via user profiles, and by invitation/report.

2 Likes

Is this “Create only” permission part of any upcoming release.? I saw this mentioned in a blog article (feedback from gaming forums).

Nope, not in any release.

If you need private communication targeted at a group of users use the messaging system. Making this more obvious and usable is on the roadmap though.

1 Like

Thanks. In that Case, can we disable PMs between users and enable PM between user and admins ?

1 Like

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.

Just to be completely sure. Is the reverse also true. Can an user always initiate / create PMs with staff ?

1 Like

Nope not if you disable PMs they cannot. Only staff can.

1 Like

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.

1 Like

Sure, they can reply to the welcome PM as needed.

Also clarification, and related, users can always reply to PMs they receive.

1 Like

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.

1 Like

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.

1 Like

One last question : Is there a way to configure another default PM for all users with a title “Reply to this message to contact staff” ?

This way I can link https://domain/users/username/messages to a “Contact” button and hope the user see this message.

1 Like

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.

3 Likes