Easy-digital-downloads: Resend Receipt button sends receipt to original purchase email

[michaelbeil]

When a user hits the "Resend Receipt" button, the receipt will be successfully sent to the email address that was used during the purchase. However, when the primary address for that user is changed (even after completely removing the original one) the receipt will still be sent to the original address.

One needs to go into the DB and manually edit the purchase record there to make it send to the new address.

We should allow the receipt and new download links to be sent to the customer's primary address instead.

[pippinsplugins]

Ready for testing https://github.com/easydigitaldownloads/easy-digital-downloads/pull/5010

[SDavisMedia]

@pippinsplugins I can't confirm this is working. I was able to replicate resending the purchase receipt to not only a secondary email address (was primary at the time of purchase), but also an email address that was deleted from the customer record. However , issue/4896 is _not_ fixing the issue for me. I still get the same exact behavior.

[SDavisMedia]

My mistake! All good on my end now. :+1: Added a little CSS:

[pippinsplugins]

@SDavisMedia can you confirm the receipt gets sent to the selected email?

Any thoughts on what to do (if anything) with the Resend Receipt list table link?

[SDavisMedia]

@pippinsplugins That's the main thing I was testing. It goes to whatever email address is selected. :+1:

As for the purchase history table, I think it should send to the customer's primary email address no matter what. I'm not comfortable with a UI enhancement there.

[pippinsplugins]

Ok we need to change the list table to use primary email then. It currently uses the payment email.

[SDavisMedia]

I took a long stab at this yesterday but couldn't quite figure out how to do it.

[pippinsplugins]

@SDavisMedia give that a try.

[SDavisMedia]

@pippinsplugins Two things:

1. Needs to work from the Bulk Edit resend receipt functionality.
2. The Email column on the payments table should probably display the email address that'll be used, so just the customer's primary email address.

The quick link/action did work. :+1:

[pippinsplugins]

I'm thinking that we may want to go ahead and make a more drastic change here.

edd_get_payment_user_email() returns the email address stored in the payment meta. It's been this way for a long time.

I think we should consider making edd_get_payment_user_email() return the customer's primary email and _not_ the email stored in payment meta. We can fallback to the one in payment meta if there is not a customer record associated with the payment (for old purchases mostly).

In the vast majority of cases, the customer email and the payment email will be identical, but in some cases, like those that started this issue, the customer email gets updated and now we're left with an orphaned payment email.

Anyone opposed to making edd_get_payment_user_email() return the customer email? That would automatically address the two points that @SDavisMedia raised above.

[cklosowski]

My only concern with this @pippinsplugins is its possible to break expected behavior. Like you said, most of the time they'll match. I think I'm ok with it, but it's going to be something we need to announce.

[pippinsplugins]

I've been trying to think of situations where it could cause issues. So far I haven't really come up with any.

Anything come to mind?

[cklosowski]

@pippinsplugins edd_ajax_generate_file_download_link and edd_get_download_file_url use the payment email address as part of the generation of the token for a download URL. If we update the behavior of this function we'll need to go through all parts of file download link generation (possibly look at SL as well) and make sure that we're using the customer email not the email on the payment.

[pippinsplugins]

Ah! Good catch.

[cklosowski]

While these two functions use edd_get_payment_user_email to get the email, the problem we'd have is making sure that all references to generating things pass in the email address on the customer.

The concern I have there is if you call edd_get_payment_user_email, we'd be returning the customer email address but if you do $payment->email it would be different.

[pippinsplugins]

Let's not adjust edd_get_payment_user_email().

Instead, I think we should update the meta value automatically when the primary email on a customer is changed.

[cklosowski]

I think that's acceptable. A question on this, while running this, if the email address on the payment is different than the customer, should we add that email address to the customer's record as a secondary @pippinsplugins ?

[pippinsplugins]

No, I don't think so. That could cause issues when changing the customer record from a personal email to a business email.

[pippinsplugins]

The email stored on payment records is now updated when the primary email address is changed on the customer. This will result in the Resend Receipt in list tables, and anything that calls it programmatically, to send the receipt to the customer's primary email (if it has been set after the purchase was created).

@SDavisMedia @cklosowski give it a new round of testing please?

[SDavisMedia]

@pippinsplugins All good here. After making a purchase and then changing the customer's primary email address, payment details switched to the primary and all resend receipt functionality sends to the primary. :+1:

[pippinsplugins]

Merged.