2015-01-01 23:19:24 +00:00
|
|
|
# This file is part of Business:PayPal:API Module. License: Same as Perl. See its README for details.
|
|
|
|
# -*- mode: cperl -*-
|
|
|
|
use Test::More;
|
|
|
|
use strict;
|
2015-01-02 17:50:57 +00:00
|
|
|
use autodie qw(:all);
|
2015-01-02 17:49:32 +00:00
|
|
|
use Cwd;
|
2015-01-02 17:50:57 +00:00
|
|
|
|
2015-01-01 23:19:24 +00:00
|
|
|
if ( !$ENV{WPP_TEST} || !-f $ENV{WPP_TEST} ) {
|
|
|
|
plan skip_all =>
|
|
|
|
'No WPP_TEST env var set. Please see README to run tests';
|
|
|
|
}
|
|
|
|
else {
|
Properly extract Options from PaymentItemInfo
The Options fields found in
/PaymentTransactionDetails/PaymentItemInfo/PaymentItem/Options have
never been extracted in the proper way. In fact, I'd be surprised if
anyone found the previous method of extraction useful at all.
I discovered this bug when I needed to lookup the Options selected
during payment, and found they weren't returned by the API.
Specifically, the value inside the SOAP tags, which is what the API
previously returned, are simply not useful: they are typically empty.
The interesting data is stored in the attributes of 'name' and 'value'.
Note, BTW, that each PaymentItem can have its own set of Options. This
code added herein properly extracts the Options data for each
PaymentItem, and places it both in the Options field for that
PaymentItem, and in the array in the PII_Options "convenience" field.
As can be seen in the accompanying changes to t/OptionsFields.t, the
return values of the Options data is now a hash rather than a list. I
believe this API-user-visible change is appropriate since a hash is
ultimately the natural representation of this data, and since having the
Options as an array of empty strings wasn't useful, anyway.
Nevertheless, if existing user code of this API relies on Options being
an array of empty strings (which I suppose could have been usefully used
in scalar context to get the count of options in the record), this
change theoretically creates a user-visible change in the API. I can't
imagine anyone found the previous return value useful in the past
anyway, so I'd be surprised if anyone relies on this mis-feature. If
they did, they can simply change their code to:
scalar keys ...{Options}
instead of:
scalar @...{Options}
However, since this is technically an API change, I've updated the
Changes file and the module documentation to mention it.
2015-01-02 18:09:50 +00:00
|
|
|
plan tests => 14;
|
2015-01-01 23:19:24 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
use_ok( 'Business::PayPal::API::TransactionSearch' );
|
|
|
|
use_ok( 'Business::PayPal::API::GetTransactionDetails' );
|
|
|
|
|
|
|
|
#########################
|
|
|
|
|
|
|
|
require 't/API.pl';
|
|
|
|
|
|
|
|
my %args = do_args();
|
|
|
|
|
|
|
|
=pod
|
|
|
|
|
|
|
|
These tests verify the options work.
|
|
|
|
|
|
|
|
=cut
|
|
|
|
|
2015-01-02 17:50:57 +00:00
|
|
|
open(OPTIONS_PAY_HTML, ">", "options-payment.html");
|
2015-01-01 23:19:24 +00:00
|
|
|
print OPTIONS_PAY_HTML <<_OPTIONS_PAYMENT_DATA_
|
|
|
|
<html>
|
|
|
|
<body>
|
|
|
|
<form action="https://www.sandbox.paypal.com/cgi-bin/webscr" method="post" target="_top">
|
|
|
|
<input type="hidden" name="cmd" value="_xclick" />
|
|
|
|
<input type="hidden" name="business" value="$args{SellerEmail}" />
|
|
|
|
<input type="hidden" name="item_name" value="Field Options Tester" />
|
|
|
|
<input id="no_shipping" type="hidden" name="no_shipping" value="0" />
|
|
|
|
<input id="amount" type="text" name="amount" size="7" minimum="120" value="120" />
|
|
|
|
<input type="hidden" name="on1" value="firstOption" />
|
|
|
|
<input type="hidden" name="os1" value="Yes" />
|
|
|
|
<input type="hidden" name="on2" value="size"/>
|
|
|
|
<input name="os2" id="os2" value="Large"/>
|
|
|
|
<input type="image" border="0" name="submit" alt="Submit Field Tester with $120 payment">
|
|
|
|
</form></body></html>
|
|
|
|
_OPTIONS_PAYMENT_DATA_
|
|
|
|
;
|
2015-01-02 17:50:57 +00:00
|
|
|
close(OPTIONS_PAY_HTML);
|
2015-01-01 23:19:24 +00:00
|
|
|
|
2015-01-02 17:49:32 +00:00
|
|
|
my $cwd = getcwd;
|
2015-01-01 23:19:24 +00:00
|
|
|
|
|
|
|
print STDERR <<"_OPTIONS_LINK_";
|
|
|
|
Please note the next series of tests will not succeeed unless there is at
|
|
|
|
least one transaction that is part of a subscription payments in your business
|
|
|
|
account.
|
|
|
|
|
|
|
|
if you haven't made one yet, you can visit:
|
|
|
|
file://$cwd/options-payment.html
|
|
|
|
|
|
|
|
and use the sandbox buyer account to make the payment.
|
|
|
|
_OPTIONS_LINK_
|
|
|
|
|
|
|
|
my $startdate = '1998-01-01T01:45:10.00Z';
|
|
|
|
|
|
|
|
my $ts = new Business::PayPal::API::TransactionSearch( %args );
|
|
|
|
my $td = new Business::PayPal::API::GetTransactionDetails( %args );
|
|
|
|
|
|
|
|
my $resp = $ts->TransactionSearch(StartDate => $startdate);
|
|
|
|
my %detail;
|
|
|
|
foreach my $record (@{$resp}) {
|
2015-01-02 17:55:05 +00:00
|
|
|
%detail = $td->GetTransactionDetails(TransactionID => $record->{TransactionID});
|
|
|
|
last if $detail{PII_Name} =~ /Field\s+Options/i;
|
2015-01-01 23:19:24 +00:00
|
|
|
}
|
|
|
|
like($detail{PaymentItems}[0]{Name}, qr/Field\s+Options/i, 'Found field options test transaction');
|
|
|
|
like($detail{PII_Name}, qr/Field\s+Options/i, 'Found field options test transaction');
|
|
|
|
|
Properly extract Options from PaymentItemInfo
The Options fields found in
/PaymentTransactionDetails/PaymentItemInfo/PaymentItem/Options have
never been extracted in the proper way. In fact, I'd be surprised if
anyone found the previous method of extraction useful at all.
I discovered this bug when I needed to lookup the Options selected
during payment, and found they weren't returned by the API.
Specifically, the value inside the SOAP tags, which is what the API
previously returned, are simply not useful: they are typically empty.
The interesting data is stored in the attributes of 'name' and 'value'.
Note, BTW, that each PaymentItem can have its own set of Options. This
code added herein properly extracts the Options data for each
PaymentItem, and places it both in the Options field for that
PaymentItem, and in the array in the PII_Options "convenience" field.
As can be seen in the accompanying changes to t/OptionsFields.t, the
return values of the Options data is now a hash rather than a list. I
believe this API-user-visible change is appropriate since a hash is
ultimately the natural representation of this data, and since having the
Options as an array of empty strings wasn't useful, anyway.
Nevertheless, if existing user code of this API relies on Options being
an array of empty strings (which I suppose could have been usefully used
in scalar context to get the count of options in the record), this
change theoretically creates a user-visible change in the API. I can't
imagine anyone found the previous return value useful in the past
anyway, so I'd be surprised if anyone relies on this mis-feature. If
they did, they can simply change their code to:
scalar keys ...{Options}
instead of:
scalar @...{Options}
However, since this is technically an API change, I've updated the
Changes file and the module documentation to mention it.
2015-01-02 18:09:50 +00:00
|
|
|
foreach my $options ($detail{PaymentItems}[0]{Options}, $detail{PII_Options}[0]) {
|
|
|
|
ok(scalar(keys %$options) == 2, "The PaymentItems Options has 2 elements");
|
|
|
|
ok(defined $options->{firstOption}, "'firstOption' is present");
|
|
|
|
ok($options->{firstOption} eq 'Yes', "'firstOption' is selected as 'Yes'");
|
|
|
|
ok(defined $options->{size}, "'size' option is present");
|
|
|
|
ok($options->{size} eq "Large", "'size' option is selected as 'Large'");
|
2015-01-02 00:06:32 +00:00
|
|
|
}
|
Properly extract Options from PaymentItemInfo
The Options fields found in
/PaymentTransactionDetails/PaymentItemInfo/PaymentItem/Options have
never been extracted in the proper way. In fact, I'd be surprised if
anyone found the previous method of extraction useful at all.
I discovered this bug when I needed to lookup the Options selected
during payment, and found they weren't returned by the API.
Specifically, the value inside the SOAP tags, which is what the API
previously returned, are simply not useful: they are typically empty.
The interesting data is stored in the attributes of 'name' and 'value'.
Note, BTW, that each PaymentItem can have its own set of Options. This
code added herein properly extracts the Options data for each
PaymentItem, and places it both in the Options field for that
PaymentItem, and in the array in the PII_Options "convenience" field.
As can be seen in the accompanying changes to t/OptionsFields.t, the
return values of the Options data is now a hash rather than a list. I
believe this API-user-visible change is appropriate since a hash is
ultimately the natural representation of this data, and since having the
Options as an array of empty strings wasn't useful, anyway.
Nevertheless, if existing user code of this API relies on Options being
an array of empty strings (which I suppose could have been usefully used
in scalar context to get the count of options in the record), this
change theoretically creates a user-visible change in the API. I can't
imagine anyone found the previous return value useful in the past
anyway, so I'd be surprised if anyone relies on this mis-feature. If
they did, they can simply change their code to:
scalar keys ...{Options}
instead of:
scalar @...{Options}
However, since this is technically an API change, I've updated the
Changes file and the module documentation to mention it.
2015-01-02 18:09:50 +00:00
|
|
|
|
2015-01-02 17:55:05 +00:00
|
|
|
# Local Variables:
|
|
|
|
# Mode: CPerl
|
|
|
|
# indent-tabs-mode: nil
|
|
|
|
# cperl-indent-level: 4
|
|
|
|
# cperl-brace-offset: 0
|
|
|
|
# cperl-continued-brace-offset: 0
|
|
|
|
# cperl-label-offset: -4
|
|
|
|
# cperl-continued-statement-offset: 4
|
|
|
|
# End:
|
2015-01-02 00:06:32 +00:00
|
|
|
|