I recently updated to PR 8 Update 7, with the major changes in log-ins. Here are my (and my customer's) problems:
Of the nearly 10,000 customers in the database, in 545 of them the "lost email" email address does not match either the shipping or billing email address. This will, (and already has), caused customers to not be able to login because their lost email address was entered way back in the day and is no longer remembered or relevant.
I have 727 duplicated customer entries. There is overlap between these dupes and the aforementioned 545 records.
The problem comes when a customer attempts to log in with their current email address. It isn't found in the "lost password address" field. I wind up getting a phone call and a slightly irritated customer.
It would be a royal pain to go through the customer database and copy the billing email into the lost passwords email field. The logic of this change assumes that they have been logging in using the billing email address with the (now removed) Emporium Plus Email Login module. I guess I can fix these records in Exel or a desktop database and import, but I hesitate to do so until I get something straight. There MUST be one field per record that is unique or the database is garbage. Obviously, the "lost password email" field is not unique. Please tell me that the "login" field is, and will continue to be, the database key (unique). If that's the case, then I can reasonably safely do an import to fix these records.
That still doesn't solve all the problems. I found in testing that when the "lost passwords email" field is used to log in, and there are multiple customer records for that field, the customer is logged into the first customer record returned. This may, or may not, be the account that the customer last used. They may not realize that the shipping address is has possibly been changed, resulting in an order going to the wrong place.
What to do about this, I do not know. The only solution I can think of involves a lot of laborious detective work (x 725). Does anyone have a recommendation?
Lastly, because my store is an old MMUI store that has been heavily customized, I have to manually update the code changes for each update. I do not see any code changes for the ACED page in the MivaPR8_10-11-12.pdf doc. This is what it looks like on my ACED screen (see attached). I assume that this should change, relabeling the "lost password email" and removing the Username field. Is that correct? Do you have code changes for this page?
Thank you.
aced.png
Kevin Garrett
Of the nearly 10,000 customers in the database, in 545 of them the "lost email" email address does not match either the shipping or billing email address. This will, (and already has), caused customers to not be able to login because their lost email address was entered way back in the day and is no longer remembered or relevant.
I have 727 duplicated customer entries. There is overlap between these dupes and the aforementioned 545 records.
The problem comes when a customer attempts to log in with their current email address. It isn't found in the "lost password address" field. I wind up getting a phone call and a slightly irritated customer.
It would be a royal pain to go through the customer database and copy the billing email into the lost passwords email field. The logic of this change assumes that they have been logging in using the billing email address with the (now removed) Emporium Plus Email Login module. I guess I can fix these records in Exel or a desktop database and import, but I hesitate to do so until I get something straight. There MUST be one field per record that is unique or the database is garbage. Obviously, the "lost password email" field is not unique. Please tell me that the "login" field is, and will continue to be, the database key (unique). If that's the case, then I can reasonably safely do an import to fix these records.
That still doesn't solve all the problems. I found in testing that when the "lost passwords email" field is used to log in, and there are multiple customer records for that field, the customer is logged into the first customer record returned. This may, or may not, be the account that the customer last used. They may not realize that the shipping address is has possibly been changed, resulting in an order going to the wrong place.
What to do about this, I do not know. The only solution I can think of involves a lot of laborious detective work (x 725). Does anyone have a recommendation?
Lastly, because my store is an old MMUI store that has been heavily customized, I have to manually update the code changes for each update. I do not see any code changes for the ACED page in the MivaPR8_10-11-12.pdf doc. This is what it looks like on my ACED screen (see attached). I assume that this should change, relabeling the "lost password email" and removing the Username field. Is that correct? Do you have code changes for this page?
Thank you.
aced.png
Kevin Garrett
Comment