After lots of support and help from others, I have finally sorted out the rawest form of how to accomplish this. It is presented below as a patch:
diff --git a/lib/email/message_builder.rb b/lib/email/message_builder.rb
index f099b11..2a69249 100644
--- a/lib/email/message_builder.rb
+++ b/lib/email/message_builder.rb
@@ -147,7 +147,15 @@ module Email
if allow_reply_by_email?
result['X-Discourse-Reply-Key'] = reply_key
- result['Reply-To'] = reply_by_email_address
+ if @opts[:private_reply] == true
+ result['Reply-To'] = reply_by_email_address
+ else
+ p = Post.find_by_id @opts[:post_id]
+ result['Reply-To'] = "#{p.user.name} <#{p.user.email}>"
+ result['CC'] = reply_by_email_address
+ end
else
result['Reply-To'] = from_value
end
This patch does the following:
By default, users who hit ‘reply to’ will only reply to the sending user.
For a user to post a public message to the mailing list / topic, they would have to hit ‘reply all’.
It does not act on private messages.
Note: This exposes the sender’s email address to all recipients.
Unfortunately, I will implement this patch for our use-case effective immediately.
However, I recognize that it would be amazing if the following were true:
A per-category or site-wide option to select this
A per-category or site-wide option to expose email addresses.
Integration into personal messages rather than via email directly.
When the responding user hits ‘reply all’ and selects both the list and the sending user, the sending user should not receive an email notification from Discourse. Currently, two messages - one via email and one via Discourse - will arrive.
I hope the patch as it is helps somebody. If I could make it a per-category option, would you guys consider folding it into the master branch, @erlend_sh?
Maybe @zogstrip can chime in here since he’s been our guy extraordinaire as of late.
If at all possible, I’d much rather have this tweak done in the form of a plugin. No other reply-by-email solution I’ve ever tried works this way. Your use case is valid, but incredibly rare.
It’s less a question of desire than ability. I’ve searched for documentation about how to develop a plugin as a Rails novice, but had no luck. Obviously I would really prefer not to have to patch core every time…
Could you point me to a simple plugin I could manipulate / use as a base to do this?
I am trying to understand how to properly make this plugin. I’m currently stuck in my plugin.rb, as it seems that I cannot properly replace the MessageBuilder class.
Here is the current plugin.rb (and the repo in general):
When I run the plugin, I get the following, which I suspect reflects that the class is not properly replaced:
/vagrant/lib/email/message_builder.rb:20: warning: already initialized constant Email::MessageBuilder::REPLY_TO_AUTO_GENERATED_HEADER_KEY
/vagrant/lib/email/message_builder.rb:20: warning: previous definition of REPLY_TO_AUTO_GENERATED_HEADER_KEY was here
/vagrant/lib/email/message_builder.rb:21: warning: already initialized constant Email::MessageBuilder::REPLY_TO_AUTO_GENERATED_HEADER_VALUE
/vagrant/lib/email/message_builder.rb:21: warning: previous definition of REPLY_TO_AUTO_GENERATED_HEADER_VALUE was here
I replaced a class method so it might need to be done a bit differently
(i.e. instance_eval instead of class_eval ?)
* and yes, the names are counter-intuitive
Definitely this seems like a step forward, since at least I’m manipulating the class, but not sure what I’m doing wrong here. I will also try to understand @Mittineague 's solution and see if I can implement it.
I’ve added a byebug both after the class and after the method to see if they are being accessed. If added after the class, it is clear that the class is being tapped. However, after the method, it is not. Have I gotten the namespace wrong somehow?
/vagrant/lib/email/message_builder.rb:20: warning: already initialized constant Email::MessageBuilder::REPLY_TO_AUTO_GENERATED_HEADER_KEY
/vagrant/lib/email/message_builder.rb:20: warning: previous definition of REPLY_TO_AUTO_GENERATED_HEADER_KEY was here
/vagrant/lib/email/message_builder.rb:21: warning: already initialized constant Email::MessageBuilder::REPLY_TO_AUTO_GENERATED_HEADER_VALUE
/vagrant/lib/email/message_builder.rb:21: warning: previous definition of REPLY_TO_AUTO_GENERATED_HEADER_VALUE was here
The require line is unnecessary and should be taken out.
There appears to be a bug where the header_args cannot be inserted into a plugin as currently written. I will report this as a bug after a bit more testing and see what others suggest as a fix
I’m also working with a Discourse site for a large number of users that were comfortable with a GNU/Mailman list. My users are struggling with the volume of email they’re receiving, because others are sending a large number of person to person messages back through our categories using the email reply option.
Unfortunately many of my users have gotten into the very bad habit of always using “Reply All” in their email clients. With GNU/Mailman this didn’t matter. While the option reply_goes_to_list = Poster was set, messages never made it back to the list unless someone intentionally added the list address.
I’m currently running your plugin on a test server. Is there any way to configure Discourse with your plugin so that the CC address won’t get added to messages? The code refers to @opts[:private_reply], but I haven’t figured out how this option gets set to true.
I tried this method on my test server too, but my users are strongly divided into email and web camps. The email users really don’t want to visit the web site to participate in discussions or reply to posters. They are going to continue to hit reply all in their email clients which makes the experience worse for everyone.
My Discourse site has login required enabled. Mailman didn’t keep email addresses private from the other list subscribers, so exposing them has never been a concern for this group.
Ideally I’d like to have the option to set the reply-to: header to the sender and provide a mailto: link in the footer that goes to the topic. That would keep the private replies off the topic, while still giving email users a way to continue the discussion without forcing them to use the web site.
It would require change to Discourse Core code, but do you think having alias email addresses for members that used Discourse as a type of relay might solve the disclosure concern?
eg. similar to the generated email address when a member is anonymized, recipients would see something like "348732@discourse.org" or "membername@discourse.org" instead of the actual email address.
Based on your description, I think that would OK. I’m assuming the generated email address would send a private message from Discourse to the original sender.
Our email users simply assume that replies from their email client will go to the sender not the topic, because that’s how most Mailman lists have worked for years. It would be nice to offer them a way to add to the topic through a mailto link in the message, but this isn’t a requirement for us.
Having Reply All go back to the topic is a problem that may very well be unique to us. My users have learned that Reply doesn’t include everyone on other emails, so they always hit Reply All. Many of these users see the CC field as just another place to enter email addresses. They don’t really understand the difference between TO and CC.