[ic] Necessity of delete $Vend::Session->{mv_order_number} in Dispatch.pm?

[Mike Heins]

Quoting John Young (john_young@sonic.net):
> Hi, all.
> 
> In IC 4.9.7+, how necessary is
> 
>      delete $Vend::Session->{mv_order_number};
> 
> at line 406 in the latest (23 Mar 03) version of Dispatch.pm?
> 
> I've been working on some custom order number generation code, and
> setting it in Session->{mv_order_number} does not work across all of my
> order routes (including setting Values->{mv_order_number}, as well).
> 
> If I set Session->{mv_order_number} in log_transaction, receipt.html
> still uses OrderCounter.  If I set Session->{mv_order_number} in 
> checkout.html,
> all logs/reports still use OrderCounter.
> 
> Assuming an order number generation usertag called order_number(), and
> using order routes like in Foundation, with "log main copy_user"
> (log - log_transaction, main - receipt.html, copy_user - mail_receipt),
> for instance, yields:
> 
> order_number() in log_tranaction
>      - custom order number in db, but not receipt
> 
> order_number() in receipt.html
>      - custom order number in receipt, but not db
> 
> Many other tests like the two above, always only obtaining custom
> order number in some, but not all desired locations.
> 
> order_number() in checkout.html
>      - custom order number nowhere

All of these are killed by the fact that the $Values array is
reset for every route.

> 
> Yet:
> order_number() in checkout.html
> AND  "delete $Vend::Session->{mv_order_number};" omitted in Dispatch.pm
>      - custom order number everywhere, all is fine.

That is a bad option. You would be assigning a new order number
every time someone loaded the checkout page....

> 
> So, the last test above works well, but I don't like to modify the
> distribution if I can avoid doing so.  Any tips?  Am I doing something
> dangerous?  If I am, would I be okay by deleting Session->{mv_order_number}
> from within, say, log_transaction, once I've committed my order number?

It was intended that the order number be set in a profile. There *is* 
a defect, however, in that the setting of $Values->{mv_order_number}
is set in the temporary values of the route. While you can fix this
by calling [data session mv_order_number], it might be better to make
it work a bit more transparently.

Perhaps this would be effective:

--- /r/Order.pm	Sat Mar 29 15:19:20 2003
+++ /rt/Order.pm	Sat Mar 29 17:06:30 2003
@@ -1583,6 +1583,12 @@
 			}
 		}
 
+		if($Vend::Session->{mv_order_number}) {
+			$value_save->{mv_order_number} =
+				$::Values->{mv_order_number} =
+					$Vend::Session->{mv_order_number};
+		}
+
 		$Vend::Interpolate::Values = $::Values = { %$value_save };
 		$::Values->{mv_current_route} = $c;
 		my $pre_encrypted;

That does appear to do it, and I have made that patch. I don't see
how it can hurt anything if you never set $Session->{mv_order_number}.

Thanks for shedding new light on this.

-- 
Mike Heins
Perusion -- Expert Interchange Consulting    http://www.perusion.com/
phone +1.513.523.7621      <mike@perusion.com>

Software axiom: Lack of speed kills.