Easy-digital-downloads: Support additional emails for customers

[pippinsplugins]

Right now customers are identified by their email address and each unique email is a different customer.

I think we should add support for adding additional email addresses to customer records. Help Scout does this really well.

Doing this would allow us to associate multiple emails with a single customer record and would resolve this problem:

[evertiro]

How do you see this working?

[pippinsplugins]

My first thought was via a separate column in the customers' DB for email aliases. Probably comma separated.

[evertiro]

Given that a significant amount of the existing setup (re: customer records) is based on email, how would that work? Would we migrate away from that and use something else? Or just have more of a 'primary' vs 'attached' email setup?

[pippinsplugins]

No, that's over thinking it.

We simply add another column to the DB and allow alternative addresses to be set. When searching for payments by email, we look both in the primary and alternative columns.

[michaelbeil]

This would be phenomenal. Re: @JustinSainton on Twitter, what about a meta approach?

[JustinSainton]

My thinking behind that is that it might be tricky to scale that - if the intent was to have a 1:1 relationship between alternate email and DB column.

A meta value, an array of alternate addresses, might prove a more reliable data store for situations where a dev, a junior dev, agency parter, client, client's client, client's cat, cat's caretaker, etc. all need access.

All that to say, @pippinsplugins is right - technical implementation matters less than the actual feature happening. kudos on a great idea :)

[1bigidea]

Just a reminder, if I am doing my job the way you (the developer) want, I'll have my email address attached to multiple end-user accounts.

This problem isn't different from reminding a user from a larger organization to use a generic email address for registering (or recovering a password) rather than a personal one that expires when an employee leaves.

[pippinsplugins]

Another problem this helps us solve:

1. Customer purchases something with [email protected] and registers an account (call it ID 1)
2. Customer now has a customer record identified by [email protected] and a user_id of 1
3. Same customer, while logged in, purchases another item but enters [email protected].
4. Purchase record is now tied to customer record of [email protected] but user_id of 1
5. Two customer records now have the same user_id column
6. The second purchase is not available in customer's Purchase History since he/she now has two customer records

When processing a purchase for a logged in user, we need to look up customers by the user ID and then alias the second email address entered.

[zackkatz]

:+1:

[pippinsplugins]

Customer meta table is ready for testing in #4311 so we can get started on this now.

[pippinsplugins]

I have this fully functional now in issue/3755.

Now I just need to build the UI to display additional emails and allow additional emails to be added / removed from the UI.

[cklosowski]

@pippinsplugins should we also allow the ability to Set as primary for a customer? would that have any benefit? It could be from either the User or the Admin side.

[pippinsplugins]

Yes I think so. I was considering adding a make_primary() method that would handle swapping the emails.

[pippinsplugins]

@cklosowski How's https://github.com/easydigitaldownloads/easy-digital-downloads/commit/58a278c548eeb48394f71f827e0410ad05a1961c look to you?

[cklosowski]

@pippinsplugins There is just one weirdness I see and that's if a logged in user uses the same email address as an existing customer, the purchase record goes through fine, the email address _is not_ added to the customer's record, but it is still set as the purchase email in the payment_meta.

Is that expected? Seems a little confusing.

[pippinsplugins]

We need to block that behavior probably, or at least block it if the email is associated with a customer record that is tied to a different user account.

[cklosowski]

:+1: I'll work up some error verbage.

[cklosowski]

@pippinsplugins I see two issues with the current method of showing additional emails, and that it leaves us very little room for a good 'management' approach. Adding actions for 'making primary' and 'removing' leaves us with room for icons only which isn't great for usability.

How would you feel about adding a list table below (i know it's not perfect) which would allow us an 'actions' column to make primary and remove, then we could use some repeatable rows logic to create new emails for the user?

[pippinsplugins]

I was toying with a list table too. I think I like that better as long as
it indicates which email is primary.

On Monday, May 23, 2016, Chris Klosowski [email protected] wrote:

@pippinsplugins https://github.com/pippinsplugins I see two issues with
the current method of showing additional emails, and that it leaves us very
little room for a good 'management' approach. Adding actions for 'making
primary' and 'removing' leaves us with room for icons only which isn't
great for usability.

How would you feel about adding a list table below (i know it's not
perfect) which would allow us an 'actions' column to make primary and
remove, then we could use some repeatable rows logic to create new emails
for the user?

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/easydigitaldownloads/easy-digital-downloads/issues/3755#issuecomment-221076135

[cklosowski]

:+1: Thanks, I'll go that route

[pippinsplugins]

I like the idea of including a link on each additional email as well for Make Primary.

[pippinsplugins]

Looking really good!

We need to add in detection for non-valid emails in the Add Email form:

[pippinsplugins]

This appears to all work really well, but here's a side effect I'm not yet sure how to handle.

1. Assume a customer makes two purchases with [email protected]
2. Same customer comes back and makes a purchase with [email protected] while logged in. This will register [email protected] as an additional email for the customer. So far so good.
3. The 3 Completed Sales link goes to Payment History filtered by the customer's email. When a customer has multiple emails, this results in only purchases made by the primary email getting displayed.
4. If an additional email is converted into the primary email, the original purchases made by the previously primary email no longer display when clicking X Completed Sales

I think we can fix both issues by changing the X Completed Sales link to use the customer ID as the filter instead of the email. This may also require a change to the Payment History table.

[cklosowski]

Yeah. Customer ID would be the best solution for the purchase links. I'll make that happen when I fix the invalid email stuff.

[cklosowski]

Ok @pippinsplugins just pushed up some improved error handling on the adding of customer emails from admin, it now logs a customer note whenever we use this form to alter the email addresses, and this also makes the completed payments link use a user customer query string item that filters the payments list table by customer ID (regardless of what email the customer has)

Next up, preventing a logged in user from purchasing with an email address registered to another customer.

[cklosowski]

@easydigitaldownloads/core-devs this is ready for some testing on both the front end (checkout) and backend (customer management screens)

[cklosowski]

@easydigitaldownloads/core-devs While testing this, let's also be sure to hit it with Auto-Register enabled. Just to be sure.

[pippinsplugins]

Some testing tips:

• Test adding emails to a customer
• Test removing emails
• Test swapping primary emails
• Test purchasing with new email after adding it
• Test purchasing with a new email (one that hasn't been added) while logged in
• Test instantiating EDD_Customer with primary and additional emails
• Test adding an email to a customer that already belongs to someone else
• Test searching payment history / customers with primary and secondary emails

[cklosowski]

@pippinsplugins I need to get the searches working properly still. I just wanted to make sure we tested the functionality of using/assigning/deleting REALLY fleshed out before we put it in the beta.

[cklosowski]

@easydigitaldownloads/core-devs So some feedback on the 'Payments' search. Right now if you type in an email address it's searching the _edd_payment_email payment meta. If we change this to search the customer, it's possible that this will miss some payments for past purchases as those email addresses are not on the customer records, just in teh payment meta.

Should we leave payment search, using the payment meta? I've got the customer search allowing searching by primary and additional email addresses.

[pippinsplugins]

@cklosowski I vote we leave payment searh as is for now.

[mintplugins]

Tested by doing a checkout with a logged-in user and using a new email address. It works great and adds the new email to the existing customer. However, I noticed the Payment History screen still has the "Customer" column blank.

Tested successfully without any issues:

• Added/removed emails to customer.
• Swapped primary emails.
• Bought new product logged out using existing secondary email - successfully used existing customer
• Purchased with a new email (one that hasn't been added) while logged in
• Test searching customers with primary and secondary emails

Did not work (as noted in previous comments as well):

• Test searching payment history with primary and secondary emails. These just bring up the payments attached to the email - as opposed to all payments by the customer.

[pippinsplugins]

Good catch.

[SDavisMedia]

I actually can't replicate @mintplugins' issue.

Everything seems to be working well for me, though.

[cklosowski]

@mintplugins @pippinsplugins We've decided to not move forward with Did not work (as noted in previous comments as well): as it's not going to provide a benefit.

[cklosowski]

@mintplugins is that with Auto Register? I'm not experiencing that. All my customers have names wether the purchase was made with the primary or an additional email.

[cklosowski]

[cklosowski]

@easydigitaldownloads/core-devs Something else I thought about here this morning, do we want to allow a dropdown in the front-end profile editor to allow a customer to choose their primary email from a list of emails attached to their customer? Also, should they be able to delete an email associated with their account on the front-end as well?

I'm hesitant to allow adding from the front-end in the beginning, but I think setting primary and removing emails could be important.

[SDavisMedia]

No clue how this didn't cross my mind but I think yes, they should be able to add, remove, and select primary from the profile editor. I vote definitely.

[cklosowski]

@SDavisMedia I think for now adding should be limited to a purchase or admins. This prevents someone from going in and adding a bunch of _known_ email addresses to their account, which would effectively prevent someone from purchasing, as an 'blackhat' method of stopping someone from buying.

[brashrebel]

What about requiring verification of every added email address?

[pippinsplugins]

I would actually prefer that we _not_ allow customers to ad emails from the frontend. While it's unlikely to be abused, the possibility is there.

We can consider adding it in the future but not right now.

If we do add it, it should definitely require verification, like @brashrebel mentioned.

[topher1kenobe]

I wouldn't worry about it. If someone can't buy they'll email the admin and complain, and then the admin will become aware of the jerk and act accordingly.

[cklosowski]

I'm with @pippinsplugins We can add it later, but it has to have a verification system.

[michaelbeil]

Agreed on the verification system if/when we add this to the front-end profile editor.

[cklosowski]

made some updates to this, there is now a section in the profile editor that does some logic to determine 3 cases:

1. User account with no customer (simply uses the user email address) with a text field
2. User is a customer, but only has one email, so it just gives a text field with the customer email address
3. User is a customer with multiple email addresses, displays a dropdown to pick an existing email address as the new 'primary', which is validated, so someone cannot hack in a new email address, and then moves the previous one to the array, this also updates the user login email, FYI.

[cklosowski]

[pippinsplugins]

@cklosowski Let's go ahead and merge into release/2.6 but leave open.

[cklosowski]

Done.

[SDavisMedia]

All tests working on my end.

[pippinsplugins]

@jchristopher found a bug that caused the The email address {address} is already in use error to show even when it shouldnt't: http://d.pr/i/Oeho

Fixed in https://github.com/easydigitaldownloads/easy-digital-downloads/commit/dcff8b5b218e34579af7cbef5423e7a8be8bbbdd

[topher1kenobe]

All tests working on my end.

[mintplugins]

@cklosowski I am still getting a blank customer on the Downloads > Payment History page. Auto Register is disabled.

[pippinsplugins]

@mintplugins Does it show customer missing on view order details or is there an email there? Does the customer just not have a name set perhaps?

[mintplugins]

@pippinsplugins @cklosowski The customer just didn't have a name. Carry on :)

[pippinsplugins]

Everything looking good here! Closing :)