Use RealName in email headers
Dane Powell - May 15, 2009 - 16:33
| Project: | Notifications |
| Version: | 6.x-2.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | duplicate |
Description
Currently emails sent via Notifications arrive from username <useremail>. On some sites, the username may not really be meaningful (on ours, for instance, usernames are a collection of letters and random numbers). I propose that on sites that have the RealName module installed, Notifications use a user's RealName in emails, so that they would be from User's RealName <useremail>. The RealName module already includes extensive privacy controls, so you would not have to worry about unintentionally disclosing information.

#1
Voting for this feature.
#2
I've tried to implement this once in the past but wasn't able to get very far. If Jose or someone else could provide some guidance I'd be happy to give it another shot...
#3
this should not be too difficult - username and realname is part of user object - you just have to find a place where message is prepared and swap these two things, or better yet make simple module that does it. i am total beginner, but even i could managed to do stuff like that if i stare at code long enough.
also you may check out latest versions of realname module, it has bypass form feature, don't know what it does thou.
#4
In theory, yes, it's that easy :) That's basically what I tried previously (see #377216: Pull user's real name from profile for use in email header) and the results were not very good. There are a few problems with this approach, the first being that there are multiple places where the user's account info is pulled in both the notifications and messaging module. These interact with each other in unexpected ways- if you override enough of them to actually get the user's name passed through, you end up breaking other things and I'm not really sure why.
#5
even not here? http://drupalcontrib.org/api/function/messaging_mail_prepare/6
#6
Huh... that's weird. I could swear that I tried that last time and it didn't work for some reason. However, now it seems to work fine, though I haven't tested it extensively. I will spend a little more time with it and try to cook up a patch.
Thanks for the pointer.
#7
Here is a simple patch that implements this. Note that the patch is actually for the Messaging module (confusing, I know...). I believe it works only if you have chosen to disclose "Full user data" in Notifications. Let me know what you think.
#8
#9
Hey,
Thanks for the patch. I didn't test it, but it looks like it works. However, there are a lot of better ways to go about this, most of which ideally wouldn't require a patch. In general, module_exists are not the best practice, and additionally adding this functionality in the mail_prepare function means a method-specific patch to messaging that makes it behave differently for mail versus SMS or other methods--not a desirable outcome. So, here is what I would suggest. 1) Just looking at realname's project page, it says using theme('username',...) will do this without a branch if it is necessary 2) Look just below, there is a drupal_alter('mail', $mail) hook, and you could change this there in your own custom module if needed without ever patching messaging (although some mail methods don't call the hook, so mileage may vary).
For a more robust solution that could make this module or realname, please look at the other generalized messaging hooks to see if you can alter the $params array for the message. Finally, the coolest thing would be to look into adding a possible messaging part for the from field which could be customized with tokens (which realname could provide) for each method and message.
Thanks,
David
#10
Also, as you may have noticed, neither the patch nor the issue have much to do with notifications in particular, and should be dealt with under messaging.
David
#11
Thanks a lot for the advice. I'll definitely think about how to best implement this, though I do think this is an okay stop-gap that will work for most people.
The reason I put this in Notifications is because in #377216: Pull user's real name from profile for use in email header Jose specifically said he thought this issue belonged there (don't know why.)
#12
Hey,
Yeah, Jose may have been right--there are hooks all over the place to do stuff like this :-) One easy one (in messaging) you might want to check out is hook_message_alter, where you can change the whole message including adding a 'from' parameter which the mail methods will read to override the default. This is a bit hacky though, although better than patching. Look into notifications to find hooks you could use there.
David
#13
Well, it doesn't matter that much which module, I guess we can do it in the one that needs the simpler patch.
I think the patch looks good, but you may also want to sue a custom profile field. So, thinking about options, will a theme function make everybody happy? (like theme('messaging_username', $account) )
Other option I can think of is a field name in a variable, but that may be less flexible.
#14
The beauty of using RealName is that it already allows you to select which profile field to pull the name from.
#15
This should probably be accommodated permanently when http://drupal.org/node/260595 is committed, ideally with arbitrary token support. This doesn't seem like quite a duplicate yet as that hasn't been done and this has a working hack patch, but try to contribute to that if you want to see this functionality.
David
#16
I think this will get taken care of in #260595: More flexible message headers