Sure, they can reply to the welcome PM as needed.
Also clarification, and related, users can always reply to PMs they receive.
Sure, they can reply to the welcome PM as needed.
Also clarification, and related, users can always reply to PMs they receive.
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.
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.
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.
I second the opinion of @KazWolfe. Permissions is completely different from messaging.
PM is concerned with getting information sent between two parties.
What we in fact need here is a full topic with all the characteristics and behaviors of a topic. However, we just want to restrict the participants of the topic due to confidentiality issues.
As far as I can see it, that’s purely a Permissions issue and not at all like a PM.
Why are we trying to push a square peg through a round hole? What we really need here, which can be solved elegantly and simply, are new combinations of standard permissions.
And I can’t understand why these permutations have not been programmed in in the first place. There are seven possible permutations (six if you discount a lone Reply which doesn’t make sense), only three are used right now. Whether you decide to allow certain permutations is another unrelated matter.
This feature would enable a Private Feedback (Drop Box) arrangement, that is otherwise impossible to accomplish in a satisfactory way in Discourse.
Deficiencies of PMs for this use case are:
I want the ability to receive Private Feedback from users that don’t have access to send PMs.
(They might be valuable participants at a real-world event, but otherwise inactive, perhaps even TL0 on the forum.)
I want the ability to not receive Private Feedback from otherwise highly trusted users.
(They might not have registered to attend an event in a particular year, and I’m seeking feedback only from actual attendees.)
I want the submitted Private Feedback to live in one place, not mixed in with PMs in general.
I want to add new Event Staff (≠ Discourse “Staff”) to be able to see Private Feedback retroactively.
I want retired Event Staff to no longer have special access to the Private Feedback.
Deficiencies of external solutions:
I want the Private Feedback submissions to be strongly tied to a user’s forum account.
(Google Forms doesn’t have a way to collect SSO-authenticated forum identities the same way it can collect submitters’ Google Account email addresses.)
I’d like Private Feedback submissions to show up in a search on our Discourse for users that are authorized to see them.
Most of these all sound like the existing email in support… that’s how team@discourse.org
works right now. If you send an email there, it creates a private topic that staff here can see, and the email originator, but nobody else.
Yup, similar but again not the same. What really need are topics that have the correct permissions pattern. Trying to do it via emails will make it complicated… What if some forums turns off emailing?
If that is the case, you should look at different free software, as we have no plans for arbitrary topic permissions on the roadmap for the foreseeable future.
I am still not following.
You allow @team
to accept private messages. Then anyone can PM the group. Email does not even need to be enabled for that.
True. But the point is, the user experience is different…
PM is still not as simple and straight-forward as creating a topic in a category. Anyone knows how to do that. Not everyone knows how to create a PM.
However, if we can set up categories just for PM’s (i.e. all topics created there are actually PM’s sent to a particular group/team), then it will work just great!
I believe I’ve read somewhere that PM’s can be categorized. Can categories be set to be “PM-only”?
Not that I’m aware of, although I remember @erlend_sh talking about something related (theoretically) but I can’t find that now.
This kind of stuff may be doable in a plugin, but as a policy we are quite strict on never mixing PMs and non PMs in topic lists
We have plans to allow tagging on pms, categories no, cause it mixes security systems
Sure sounds like a web form that emails to your version of team@ would cover your feedback situation nicely. Web form-to-email solutions abound.
Er… so how do I go about setting this up? Sending email to the forum to automatically create a private topic? A link to some docs will be great!
And can the topic be restricted to members of a certain group, instead of having them be staff?
I think @sam had the better point here, simply experiment with group PMs first to get a feel for how it works.
The only thing email-in adds to the mix is staged accounts based on someone’s email address. And of course emailing-in.
OK. I found email in
in the Email settings. Let me try it out…
The reason being I have disabled messaging for all users. Which means PM’s go one way only.
True however users can always reply to any PM they get.
OK. Got that working. Actually the following is not particular clear:
pop3 polling enabled
- standard description is Poll via POP3 for email replies.
However, if this is not turned on, email in
will not be polled also. So, it really should be Poll via POP3 (necessary for email replies and email in).
I had it off because I don’t have email reply
and pulled out some of my hair.
Use SSL while connecting to the POP3 server
can conflict with pop3 polling port
. If pop3 polling port
is set to 110 (which usually means non-SSL), it still tried to use SSL and failed silently. Need to look at the logs to find out that OpenSSL was failing on pop3 connect.
The category setting is misleading. Custom incoming email address:
probably should be Create topics from emails sent to:
The account/address is the recipient/destination address, not the incoming/sender address.
One question though:
A somebody emails in. A topic is created under a specified category. Users allowed into the category can see it and reply to it. After a while the originator gets an email with the replies. All is great.
But if the originator is only a staged user, then he won’t get these emails. He wont get any response.
And how does he reply back? If email reply
is NOT turned on? Why – my company’s email server doesn’t support wildcards.