Mike Heins replied to my questions about Session->{mv_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.
No, thank you for replying and committing a fix so quickly. It's not the first time you've done that when I posted a question, and I really appreciate it. Your fix above works perfectly. I also moved my custom order number usertag call from checkout.html into the order profile referenced in checkout.html (according to my understanding of your earlier hints). That seems to work well, too. Yet another nice little example of Interchange's extensibility. Thanks, again, Mike! John Young _______________________________________________ interchange-users mailing list suppressed http://www.icdevgroup.org/mailman/listinfo/interchange-users
Mail converted by mhonarc 2.6.15
This archive provided courtesy of JSW4.NET, Internet Hosting Services for Small Business.