[ic] RFC: Payment.pm map_actual() modification to preserver empty b_address2

[Mike Heins]

Quoting John Young (john_young at sonic.net):
> 
> In Payment.pm, map_actual() creates %actual for data submittal to 
> payment gateways.
> 
> It performs a nice fallback of looking in $::Values, then \%CGI::values, 
> and lastly
> filling in any b_ variables with values from non-b_ variables if the b_ 
> variable is
> empty (ie, if 'b_address1' has no value, it falls back to using the 
> 'address1' value).
> 
> That is fine mostly, except in a case such as the b_ variables are 
> filled out as
> you wish, and you have intentionally left b_address2 empty.  If address2 
> contains a
> value, $actual{b_address2} is set to address2 (which is not desired). 
> This only
> affects what is sent to the payment gateway, so it's not a big deal, for 
> the most part.
> I only noticed the problem when reviewing receipts from the payment gateway.
> 
> I have modified my Payment.pm as follows:
> 
> --- Payment.pm.orig	Thu Dec 12 19:22:27 2002
> +++ Payment.pm	Fri Sep  5 01:34:50 2003
> @@ -182,6 +182,7 @@
>  	foreach $key (keys %map) {
>  		$actual{$key} = $vref->{$map{$key}} || $cref->{$key}
>  			and next;
> +		next if ( $::Variable->{BILLING_NULL_OKAY} && 
> $::Variable->{BILLING_NULL_OKAY} =~ /\b$key\b/ );
>  		my $secondary = $key;
>  		next unless $secondary =~ s/^b_//;
>  		$actual{$key} = $vref->{$map{$secondary}} || 
>  		$cref->{$map{$secondary}};
> 
> 
> ...and added to catalog.cfg:
> 
> Variable BILLING_NULL_OKAY  b_company b_address2
> 
> (even though 'company' and 'b_company' are not in the list through which
> map_actual() iterates at the moment)
> 

I think this qualifies as a behavior that should be the default. I thought
it was, but if it is not it should be.

I will look into it.
-- 
Mike Heins
Perusion -- Expert Interchange Consulting    http://www.perusion.com/
phone +1.513.523.7621      <mike at perusion.com>

Software axiom: Lack of speed kills.