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

[Jack Cushman]

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