[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)
> 
> 
> Any comments or suggestions for a better solution are welcome!

I have thought about this one quite a bit. I think the best thing
to do is have a set of indicators to sense whether a transfer
of the fields is necessary (I chose b_address1 and b_city), and
a set of fields that will be always transferred enmasse, which I
chose as:

	b_address1
	b_address2
	b_address3
	b_city
	b_state
	b_zip
	b_country

These would be set by default, and could be modified in the variables
MV_PAYMENT_BILLING_INDICATOR an MV_PAYMENT_BILLING_SET. (The MV_ is
wanted when the variable is going to be put in the core.)

The result of this is that those fields would be transferred enmasse
or not at all. The other b_ fields not in MV_PAYMENT_BILLING_SET
would be transferred as they are now.

Thanks for bringing the problem up!

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

If you think nobody cares if you're alive, try missing a couple of
car payments.  -- Earl Wilson