It is my understanding that if a customer has an email address in the database, but it is not associated with a web login (in T_CUST_LOGIN), then that customer will be unable to use that email address to register for a new web login (due to the preexisting address) and will also be unable to recover the account online (due to the lack of an actual login to recover).
Assuming that is true, would anyone recommend a good workaround for this situation? The best I can come up with is to create a procedure that runs periodically and creates web logins for email addresses that haven't already been associated with a login. This seems pretty clunky, though. Thoughts?
If the person doesn't have a web login then if they go to use that email address to create a login, they'll create a duplicate account, with the same email address, one account having a login associated with the email, one without. We have patrons who do this all the time, and then it's just a matter of merging. It may be a useful/good idea to create temporary logins for all email addresses that don't have logins, especially if your users use their email address as the login. In the situation above, I believe you wouldn't be able to create a login for the original because of the dupe the patron created and its having a login already associated with the email address. But if the login had already been automatically created, then the patron might be prevented from creating the dupe because they would be able to recover the login (even if they didn't know it existed). Of course there's always people who'll just create a new account using a different email, but that's a separate matter...
If the person doesn't have a web login then if they go to use that email address to create a login, they'll create a duplicate account, with the same email address, one account having a login associated with the email, one without. We have patrons who do this all the time, and then it's just a matter of merging.
It may be a useful/good idea to create temporary logins for all email addresses that don't have logins, especially if your users use their email address as the login. In the situation above, I believe you wouldn't be able to create a login for the original because of the dupe the patron created and its having a login already associated with the email address. But if the login had already been automatically created, then the patron might be prevented from creating the dupe because they would be able to recover the login (even if they didn't know it existed). Of course there's always people who'll just create a new account using a different email, but that's a separate matter...
Thank you, Ms. Dean and Ms. Freeman. I'll proceed with building a nightly-run procedure to create logins for unassociated email addresses. If the same address exists multiple times, I suppose I'll just have to pick one arbitrarily and leave it to the merging process to reconcile.
Does such a procedure already exist, or is it up to us to code our own?