I didn't like the default behavior that registration emailed all registrants with the 'To' field, so I made some small modifications so that instead the module emails the sender and bccs all the recipients. Not sure if this is something you'd want to roll into the module or not, but in case anyone else is interested:

function registration_mail($key, &$message, $params) {
  $subject = $params['subject'];
  $body = $params['message'];
  $message['subject'] .= str_replace(array("\r", "\n"), '', $subject);
  $message['body'][] = drupal_html_to_text($body);
}

becomes 

function registration_mail($key, &$message, $params) {
  $subject = $params['subject'];
  $body = $params['message'];
  $message['subject'] .= str_replace(array("\r", "\n"), '', $subject);
  $message['body'][] = drupal_html_to_text($body);
  $message['headers']['Bcc'] = implode(",",$params['Bcc']);
}

Inside the registration_send_broadcast function:

$params = array(
      'subject' => $subject,
      'message' => $message,
      );

becomes

$params = array(
      'subject' => $subject,
      'message' => $message,
      'Bcc' => $recipients,
    );

and finally:

$result = drupal_mail('registration', 'broadcast',
      implode(', ', $recipients), $language, $params, $from
    );

becomes

$result = drupal_mail('registration', 'broadcast', $from, $language, $params, $from);

I'm not sure exactly how to write a patch file or I'd provide that instead; I suppose to be really slick the option of how to email registrants could be configured in admin/structure/registration, but that's even further off for me.

Comments

ansorg’s picture

ansorg commented

Vote for making this the default behavior in the module, thanks

geert’s picture

geert commented

I also prefer to have the participants in BCC, rather then in TO. However, the TO should have an email as well I think. The same as the sending address?

danweasel’s picture

danweasel commented

That's what my changes do, the third argument to drupal_mail is the 'to' field and instead of sending it the calculated recipients:

implode(', ', $recipients)

I'm sending it:

$from

levelos’s picture

levelos commented
Status: Needs review » Needs work

Great catch. I'm wondering if it would be better to send an individual email to each registrant (how signup works) rather than a single email with multiple recipients? The approach Registration is currently taking is certainly more performant since it processes only one rather than one for each registrant, the tradeoff being it's not individually addressed to the recipient.

My inclination is to send them individually, even if it's a performance hit, to reduce the risk of getting marked as spam, etc.

Thoughts?

danweasel’s picture

danweasel commented

Are there spam filters out there that don't understand BCC? In the admittedly minuscule testing I did with gmail the broadcast messages seemed to be displayed fine without any false positives. But if that's not widely the case, multiple emails might be more reliable.

Since registration is already sending a single message, if you wanted to write the code to send multiple messages instead, how much extra work on top of that would it be to write a new function instead of replacing the existing one? Then a configuration option could be provided for users to choose?

levelos’s picture

levelos commented
Status: Needs work » Fixed

I went with the individual email approach. Seems a safer and more flexible (E.g., tokens in subject line, etc) approach. Committed in 8c49151.

kiphaas7’s picture

kiphaas7 commented
Status: Fixed » Needs work

I personally dislike this behavior. For small websites, where the users know eachother, it might actually be preferable to have recipients in the CC. Usually, 1 e-mail is sent from the site, from which discussion follow via e-mail.

I understand your point, but I'd really, really like a config option for this :).

danweasel’s picture

danweasel commented

As a default for the current state of the module, individual message behavior has to be superior, since it doesn't break the usefulness for your case but the original state would break it for any design where user emails should be hidden from each other.

Now, obviously a configuration option is the best of both worlds so that the admin can choose their preferred behavior from (individual messages/CC/BCC), but that's probably more significant a change than just tweaking the registration broadcast function. I'll probably keep working on it as a long term project, but I'm still new to Drupal coding. That option certainly should eventually be part of the main Registration code, but I don't think it's critical.

As a workaround to get the functionality you want (which is a neat idea, using registration broadcasts as email discussion starters), you could create a dummy user with a mailing-list email address that you register for all nodes where you want this functionality, then direct your users to subscribe to that mailing-list. Or you could create a forum topic and link to it in your email, which is probably what I will do if I ever need to accomplish something along the lines of what you suggest.

And by the way, thanks for the rapid responses and fixes levelos; love the module and hope development keeps charging forward.

levelos’s picture

levelos commented
Status: Needs work » Closed (fixed)

Thanks for the feedback guys. I'm going to leave as is for now, that is individual emails. I think it works best for most use cases and I don't want to clutter/confuse the settings screens with more options at this time.

kiphaas7’s picture

kiphaas7 commented
Status: Closed (fixed) » Fixed

Sorry for the status juggling, but this way it still shows up in the issue list. And actually, drupal bot closes an issue automatically after 2 weeks.

If you don't want to clutter the config settings (makes sense), would you add a hook/drupal_alter to registration_send_broadcast()? That way I can make a custom module overriding just those parts of the code (cc instead of single mail) myself.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

  • levelos committed 8c49151 on 7.x-1.x, panels, any-entity, slots, integrations, hold_state 
    Send email to each individual registrant when calling...