I didn't find any tickets requesting this, but it seems pretty reasonable to integrate with the tokens module rather than using static strings (@requestee_name, @requestee_link, etc...) when configuring the notification templates located at admin/user/relationships/settings


alex.k’s picture

Sure, a patch would be most welcome. Thanks.

Harry Slaughter’s picture

Yeah, I know I should be submitting a patch :) Unfortunately, it's not a high priority feature for me right now, and I don't have extra time right now, but I wanted to create a ticket for the feature to see if there's any general interest in this.

alex.k’s picture

Priority:Normal» Minor
Status:Active» Postponed
MisterSpeed’s picture

Assigned:Unassigned» MisterSpeed
Status:Postponed» Active
MisterSpeed’s picture

Priority:Minor» Normal
Status:Active» Needs review
new1.32 KB
new8.89 KB
new3.9 KB
new511 bytes

I have submitted patches for using tokens instead of hardcoded string replacements

Three patch file for user_relationship_mailer module and zip file contains newly added inc file for the token replacements

Thanks [LS]

jaydub’s picture

I'd say that rather than force the use of tokens that the default implementation continue to be supported and IF Token is installed then tokens can be used for replacements as well.

alex.k’s picture

The amount of code needed to keep both implementations would be too much... just think of the maintenance needed when changing any messaging code. So, we should stick to one or the other.

Actually, how much of a stretch is it to include token functionality as part of the move to Notifications/Messaging framework? This was identified in http://drupal.org/node/344366#comment-1456188. Then, we can keep user_relationship_mailer as is, and use the token goodness with Notifications.

rjbrown99’s picture

+1 for token support.

Why? Because of the integration with the content profile module. If you have a CCK-based profile with fields for first name, last name, and others it would be a very standard and nice integration to be able to call upon them via the token module. The customized e-mails will look a lot better.

I'm going to test the patch with the latest release of code. Thanks for submitting it.

It sounds like the longer-term plan based on the above link is to create a sub-module to enable messaging/notifications/token integration. I'm all for that if it works - whatever gets tokens into this is good for me.

rjbrown99’s picture

OK, it's a year and a half later and I'm still maintaining my own fork of this patch :) Is anyone else interested in token support for UR? I'd like it for both informational messages and e-mail options for UR Mailer.

YK85’s picture

+1 subscribing

MisterSpeed’s picture

Well, we can use the patch above and pass the strings through a method that replaces default tokens in the patch if Token is not installed, otherwise uses Token to do the hard work. It would be about as heavy as check_plain() in terms of processing costs, and would allow both variants to function from the same codebase.

YK85’s picture

I was wondering if anyone has been able to further develop the integration of tokens into UR?
Thank you

rjbrown99’s picture

Status:Needs review» Fixed

It has been 3 years that I have been maintaining my own fork of this so I decided to fix it up and turn it into a real project. Here it is:


This is the User Relationship mailer module, with additional support for tokens, the content_profile module, and Wysiwyg fields. I'd appreciate it if any of you who were interested in this originally and still have a need could help by testing it and creating bug/feature requests. Thanks!

Status:Fixed» Closed (fixed)
Issue tags:-token

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