More flexible message headers
moshe weitzman - May 20, 2008 - 11:19
| Project: | Messaging |
| Version: | 6.x-2.x-dev |
| Component: | Code |
| Category: | task |
| Priority: | critical |
| Assigned: | Jose Reyero |
| Status: | needs review |
Description
Due to user requests, OG adopted a very flexible way for admin to configure the From address. Perhaps that could be used in Notifications.
Default Value
--------------
@user_name <@site_mail>
Description Text
---------------
Specify the format of the "From:" field on outgoing notifications. Available variables: @user_mail, @user_name, @site_mail, @site_name. Note that the @user_mail token reveals the author's email address. If the admin email examples above appear blank, you need to set your site email in the Site Configuration panel.
Code for calculating From
-----------
<?php
$variables = array(
'@user_mail' => $account->mail ? $account->mail : variable_get("site_mail", ini_get("sendmail_from")),
'@user_name' => mime_header_encode($obj->name),
'@site_mail' => variable_get("site_mail", ini_get("sendmail_from")),
'@site_name' => mime_header_encode(variable_get("site_name", 'Drupal')),
);
$from_mail = strtr(variable_get("og_email_notification_pattern", '@user_name <@site_mail>'), $variables);
?>
#1
This looks really like something we'd like to have. However, as this is not only about email, but also sms, im, etc, we need to architect some better solution here.
The messaging module already supports some mail specific features, and the notifications part already can pass on the 'sender_account' plus we have some hook_message_alter().
So I'll be thinking of some better solution for the messaging layer, but in the meanwhile that feature can be implemented using already existing hooks.
Attached the current Notifications options, that I think should be enough at that level
References:
messaging_mail_headers()
hook_message_alter(), from messaging_message_send()
Mail2web module, http://drupal.org/project/mail2web
#2
Hi,
I´m using latest stable releases from OG and this module (2.x versions).
And I cannot get neither of those things that you´ve said:
Broadcast messages won´t be sended with this from: @user_name <@site_mail>
Nor the attachment notifications option would work (I´ve set it exactly as the screenshot), the broadcasting emails will be send as from the site´s email address.
Maybe I´m doing something wrong?
Thanks for your help!
Rosamunda
#3
Sorry, didn´t saw this issue post whith the info about this bug
#4
I think this issue http://drupal.org/node/463796 concerning a request for realname support in email from address could be easily incorporated here and should be. To me it seems we should go the route of making the usual message part for 'from' and providing standard defaults per send method and all the relevant tokens if they don't exists already. The handling code for when notifications talks to messaging might have to change a bit to incorporate that and send on the from information. Check http://drupal.org/node/371596 for an easy example in the patch of sending on additional info to messaging. I could get on this and/or the attachments issue.
David
#5
Also, perhaps we should incorporate flexible To fields in this as well. Maybe make just one part called "Addresses" or something, and each line would be parsed depending on which method it applies to--Mail method might look for from then to then bcc etc, others for just from and to, etc... See http://drupal.org/node/463098. This is just a thought and would need to be reviewed, specced out a bit.
David
#6
I'm making this critical because at least two other requests could be remedied by a sufficiently robust solution to this one and should be postponed pending a resolution here.
David
#7
Looks like a great idea! I think this would be a huge boon for Notifications, and looks like a very elegant / extensible way of solving several other issues.
#8
I agree that being able to configure the "from" and "to" addresses for each sending method using Tokens would be a great idea. I'm thinking this should be implemented at admin/messaging/template or admin/messaging/settings/method. Also, just to be clear, we are talking about using actual Tokens here, correct? (rather than our own implementation of "tokens")
I'm not clear on how configuring sending options such as BCC and CC recipients would play into this. I feel like that is still a separate issue. David, can you give us a clearer idea of how you think this should be incorporated?
#9
Would this be something better implemented in the Notifications Add-ons package? Perhaps as a notifications_address or messaging_headers module?
#10
Actually "tokenizing" the from headers turned out to be fairly trivial to implement for mail methods by simply modifying messaging_mail_prepare and adding a couple of options to admin/messaging/settings/overview. This code probably isn't perfect but works fine.
If we take this approach, do we even need to have the "Notifications sender" option at admin/messaging/notifications? Right now I think that will override any tokens you use to configure the mail headers, which is somewhat non-intuitive and redundant if we allow headers to be customized for each method.
Adding options to modify the sender (i.e. to add the sender's name) will not be quite as easy and will need to be implemented here as well as in each individual sending method I think.
#11
Gonna test it... THANKS!
#12
Whoops... small typo.
#13
I am noticing some strange behaviour that may or may not be related to this patch. Let me know if you see anything like this or know what it might be. I can't reproduce it or discern any pattern, but every now and then I get an email with the following header:
Joe Schmo <Joe Schmoe <">"@siteaddress.example.com>when it should obviously beJoe Schmoe <joeschmoe@example.org>#14
Ah, figured it out- I was feeding it the tokens for the currently logged-in user rather than for the node author. Silly me :)
This patch fixes that, plus is a bit tidier and fixes another minor bug.
If this looks like a good solution to people, I can work on polishing it up and getting it ready for committing.
#15
#16
This looks good. Moving to Messaging.
I think this should be a pair variables, one for 'user mails', one more for 'site mails' both like: [user] <[mail]>
I'm going to release a new version this week, will consider this for the beginning of the next release cycle, so it can be tested properly.