Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.The default setting for the Send To for a purchased Role expiration and revoke notice is set to "[user-mail] The email address of the currently logged in user". Which literally sends the notice to the logged in user instead of the person who is expiring and I don't see any token that has anything to do with the actual Role order email. So is this a bug or does anyone know what's going on here.
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | 450508_user_mail.patch | 1.18 KB | Island Usurper |
| #1 | 450508.role_mail_user.2.x.patch | 1.64 KB | cha0s |
Comments
Comment #1
cha0s CreditAttribution: cha0s commentedYeah, you're right. This should be the correct behavior.
Comment #2
b0b CreditAttribution: b0b commentedThanks for that! I only did one test, but it appears to be working now.
Comment #3
Island Usurper CreditAttribution: Island Usurper commentedYep. Looks good. Committed.
Comment #5
recrit CreditAttribution: recrit commenteddid this slip through the cracks for rc6?
uc_roles.ca.inc: lines 130 and 176 show [user-mail]
Comment #6
recrit CreditAttribution: recrit commentedadding to my previous post after debugging some more...
I was not receiving expiration reminder emails, so started looking into it and noticed they were going to my currently logged in account that was running the cron. I found this issue and look at the uc_roles.ca.inc code and indeed it sets the default to [user-mail] (still has last half of the patch from #1, but not the [mail] patch). So instead of using the patch, I changed the setting in the conditional action to [mail]. To my surprise, I still got the reminders at the wrong address. Following the debugging further down the line to uc_roles_action_user_email I found the problem.
$order is never passed to this function so the uc_order_user_load function will output the global user and this will be used in the replacements for the recipient address. This appears to be a copy-paste error from uc_roles_action_order_email which does have $order passed to it.
FIX: remove line 350
Comment #7
Island Usurper CreditAttribution: Island Usurper commentedYeah, it was either copypasta, or there was a bad merge from another patch. Repatched and committed.
Comment #8
recrit CreditAttribution: recrit commentedlooks good, thanks for the quick response!