Allow reply-to individual instead of topic/forum (mailing list feature)

[tarek (Tarek Loubani)]

I’ve been playing around with the code, and arrived at this:

In line 148 of lib/email/message_builder.rb, this would result in what I would like to do:

      if allow_reply_by_email?
        result['X-Discourse-Reply-Key'] = reply_key
        result['Reply-To'] = "test1@test.com"
        result['CC'] = reply_by_email_address
      else
        result['Reply-To'] = from_value
      end

However, now I’m trying to figure out what the ‘sender email address’ variable would be in ruby world…

[tarek (Tarek Loubani)]

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:

1. By default, users who hit ‘reply to’ will only reply to the sending user.
2. For a user to post a public message to the mailing list / topic, they would have to hit ‘reply all’.
3. 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:

1. A per-category or site-wide option to select this
2. A per-category or site-wide option to expose email addresses.
3. Integration into personal messages rather than via email directly.
4. 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?

[erlend_sh (Erlend Sogge Heggen)]

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.

[tarek (Tarek Loubani)]

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?

[codinghorror (Jeff Atwood)]

I’ve searched for documentation about how to develop a plugin as a Rails novice, but had no luck

Beginner’s Guide to Creating Discourse Plugins

[tarek (Tarek Loubani)]

Hello all,

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):

https://github.com/tareko/replyto-individual/blob/master/plugin.rb

I have tried to understand how to do this by reading a few topics I could find in searches, but as of yet no luck:

• Beginner’s Guide to Creating Discourse Plugins 1 2 3 4 5 6
• Basic plugin template
• Plugin Tutorial #1 - How to manipulate the text in the composer?
• Plugin Tutorial #3 - How to add a button after every posts?

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

Any thoughts or advice?

[Mittineague]

@tarek

Any thoughts or advice?

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

Kinder Guardian - let New members message Staff

Without this plugin, New members can only contact Staff by email or by replying to their Welcome message This plugin allows them to message Staff from either the Staff members User Card, or the Staff members Profile page. It does not let them send messages to non-Staff members. display the Flag icon or it’s option to send a message from its modal. let them send messages from their own Profile page. let them send messages if the site has them disabled https://github.com/Mittineague/discour…

[simon]

Take a look at this for how I have reopened the Email::Sender class:

https://github.com/scossar/twilio-notifications/blob/master/plugin.rb

RubyMonk - Interactive ruby tutorials to learn Ruby

[tarek (Tarek Loubani)]

Simon, that seems to definitely change things, but now the class is totally unusable with the error:

Jobs::HandledExceptionWrapper: Wrapped NameError: uninitialized constant MessageBuilder

I’ve posted a Gist of the changes I made to mimic yours here:

https://gist.github.com/tareko/c94b7dd8a24e9845617e157ec0899e43

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.

[tarek (Tarek Loubani)]

OK, I think I got it going by removing the after_initialize. Thank you!!!

[tarek (Tarek Loubani)]

Hmm. Unfortunately still no dice.

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?

Here’s is the most recent gist.

Incidentally, this error remains:

/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

[simon]

Maybe try something like this, just to see that everything is connected:

after_initialize do
  Email::MessageBuilder.class_eval do

    def body
      'hello world'
    end

  end
end

If you send yourself a password reset email, you should see ‘hello world’ as the text.

[tarek (Tarek Loubani)]

OK, a few remarks:

1. The require line is unnecessary and should be taken out.
2. 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

[tarek (Tarek Loubani)]

Finally, success!!!

I discovered the error logs (wow… how did this take so long!) They are at: http://127.0.0.1:4000/logs on a vagrant install.

I saw the following error:

Job exception: uninitialized constant MessageBuilder

Which led me to add Email::

Now, the plugin is working!!! Thank you @simon and @Mittineague!!! Now the plugin’s first working version is done. I will post more soon.

[tarek (Tarek Loubani)]

Here is the plugin, which is working as best as I can tell:

https://github.com/tareko/discourse-replyto-individual

Thank you again to all of those who have helped!

[alankeny (Alan)]

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.

[scombs (Steve Combs)]

You can see how I added the private reply option with a link in the email footer at

Email notification footer with links for Reply Privately, Sender Profile, and User Profile

To help transition listserv and email users to the online forum, I added the following footer to the reply-by-email notification. I thought I would share. The email footer View Thread or reply to this email. Your response will be posted to the site and emailed to the group. Reply to sender privately about this topic. Visit sender’s profile for more info. Update your profile and set your email preferences. View Email Tips for help on posting by email. How to implement Admin -> Customi…

Exposing the email was a limiting factor for me with this plug in.

Also not sure users would understand the reply vs reply-all distinction so I like the link method better.

[alankeny (Alan)]

You can see how I added the private reply option with a link in the email footer at
Email notification footer with links for Reply Privately, Sender Profile, and User Profile tips & tricks

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.

[Mittineague]

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.

[alankeny (Alan)]

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.