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

Thomas J.M. Burton tom at globalfocusdm.com
Wed Jan 5 17:17:21 UTC 2011


On 1/4/2011 6:49 PM, Paul Jordan wrote:
>> 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).

Ah, now that's a simple and effective way to address this situation, I 
guess I was too deep in the forest to see that one myself. Thanks for 
the suggestion, I think it will work perfectly! :)

Cheers,
Tom


!DSPAM:4d24a7aa293801331683882!





More information about the interchange-users mailing list