[ic] Necessity of delete $Vend::Session->{mv_order_number} in Dispatch.pm?
Mike Heins
interchange-users@icdevgroup.org
Sat Mar 29 17:12:02 2003
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.