[ic] Is Auto-creation of User Accounts Necessary?

[Paul Jordan]

> On 1/3/2011 9:45 AM, Paul Jordan wrote:
> > > My question is, would an IC catalog set up using the old foundation 
> > demo
> > > (from version 5.4.2 or earlier) require auto-creation of accounts for
> > > all orders, or is that something that I could remove from the
> > > transaction process without causing problems?
> > >
> > > I realize that IC catalog setups can vary greatly, so I'd also like to
> > > know if there is anything in Interchange's core that depends upon each
> > > transaction having an associated user account.
> > >
> > > I'm currently running version 5.4.2 (yes, we'll be upgrading soon!).
> >
> >
> > Switching from allowing auto creates to only user created accounts is 
> > as easy as requiring login at check out.
> > ...
> > Note that *standard/foundation* needs to create a userdb record at 
> > checkout if the user is not logged in. If you are requiring login from 
> > now on, you no longer need auto-creates - BUT - I would not go ripping 
> > out auto-create code out of the transaction process. Just requiring 
> > login is enough to skip all that code and keep everything upgrade 
> > friendly.
> >
> 
> Thanks for the reply, Paul. That information helped to confirm that I'm 
> understanding the account system correctly. The catch here is that my 
> client doesn't want to require login at check out, but have it as an 
> option for those with an account and leave a "quick checkout" option for 
> those who don't and don't want one.
> 
> My reasoning behind wanting to remove the auto-create from the 
> transaction process is to keep a cleaner userdb, considering a couple of 
> possible scenarios:
> 
> - If user with an account for some reason places an order without 
> logging in, there will then be two (or more) accounts in the system with 
> their e-mail address.
> 
> - If a customer uses the "quick checkout" (no login) option on their 
> first visit then decides to make another purchase and create an account 
> at a later date, there will be multiple accounts belonging to their 
> e-mail address.
> 
> This would create a need to be monitoring accounts and merging them so 
> that customers can access order histories from one account. 
> Additionally, if a customer creating either of the situations described 
> above forgets their password and uses the "forgot password" lookup, 
> they'll have multiple accounts which creates a confusing situation for 
> the customer and doesn't provide for a user-friendly experience.

 
In your scenario of a "quick checkout" can they retrieve their order history? I presume not right? So no, this does not create a need for maintenance. You are taking it upon yourself to maintain it to provide a feature that is not within your original design.
 
I agree though that this does case some issue with password retrieval. Just do this - in your "account creation" routine, set a field in userdb (like "real_user") to a non negative value. Autocreates at checkout won't set this field. Then in your password retrival routine, only return info for userdb records with this field set - thereby ignoring all autocreates.
 
Maybe you can use these ideas (opposite wise) somehow along with the "inactive" field, and set autocreates to inactive, and would probably hide some of them in Admin (just a guess).
 
Paul