[ic] IC 5.0.0 sending ship_notice with customer data to wrong customer?

[Duane Hinkley]

Jack Cushman wrote:

>Hi --
>
>Running IC 5.0.0, we recently ran into a problem where about one in four
>Signio transactions had already been settled without being told to. We'd
>go to the Order Status page, paste in the tracking number, click 'update
>the order' with all defaults set, and get an error saying the
>transaction had already been settled. I don't really have any leads
>about what causes it, and would love any advice.
>
>As a side effect, we started seeing customer emails being sent to the
>wrong email address. It turns out that, when a successful settlement was
>followed by a failed settlement, both users would receive the first
>one's ship notice email. This obviously doesn't help to build consumer
>confidence.
>
>Looking at the code, this is what I think is happening (it may be fixed
>in 5.2):
>
>* During a successful settlement, update_order_status.tag sets
>		    $::Scratch->{ship_notice_order_number} = $on;
>                $::Scratch->{ship_notice_username} = $user;
>                $::Scratch->{ship_notice_email} = $trec->{email}
>	order_status.html then sends the email:
>	  [if scratch ship_notice_username]
>        [email-raw][include etc/ship_notice][/email-raw]
>        [/if]
>* The next settlement fails. It first sets
>			$::Scratch->{ship_notice_username} = $user;
>                  $::Scratch->{ship_notice_email} = $udb->field($user,
>'email')
>	Then returns null. The email code above still runs, and sends a
>ship_notice email to $::Scratch->{ship_notice_email} -- using
>$::Scratch->{ship_notice_order_number} from the first order, which
>hasn't been overwritten.
>
>I don't always grok IC internals, but if this is still a bug, it seems
>like a couple of fixes would be called for:
>
>* add delete $::Scratch->{ship_notice_order_number}; at the top of
>update_order_status.tag
>* Modify etc/ship_notice to mail to [loop-data transactions email]
>instead of [scratch ship_notice_email], so that customer emails can in
>no scenario be sent to the wrong email address.
>
>Let me know what you experienced internals folks think the fix should be
>(or was -- I apologize if it was posted and I missed it). I've
>implemented the second part in the meantime. I'd also be grateful for
>any hints about what could be causing the premature settlements in the
>first place.
>
>Thanks,
>Jack Cushman
>
>_______________________________________________
>interchange-users mailing list
>interchange-users at icdevgroup.org
>http://www.icdevgroup.org/mailman/listinfo/interchange-users
>  
>

Jack,

I concurre 100% with your findings.  I just finished finding exactly 
what you found.  I put a temporary fix in place for my client by 
changing the To address the same way you did.  I planned on posting my 
findings and found you just posted the exact same problem.

I checked the CVS and I'm usring the latest version of the 
order_status.html, ship_notice and the update_order_status.tag.  So I 
don't think anyone has fixed this problem.  Have you implemented your 
change to the update_order_status.tag and is it working correctly now? 

If that worked, we can propose the fix to the core group.


Sincerely,

Duane Hinkley
Down Home Web Design, Inc.
(208) 424-0572 Fax(208) 587-0738

duane at downhomewebdesign.com
www.downhomewebdesign.com