Makefile.PL was originally in this repository but removed by Olaf at
one point in favor of the Perl Dist::Zilla system. However, to ease
instructions for Conservancy folks who want to use this library to
run our legacy PayPal importer, I've restored the files in this soft
fork of upstream. This way, Dist::Zilla need not be installed to
build these libraries.
This uses PayPal's SOAP API in a similar manner to other parts of this
API.
I adapted this about a year ago to provide these functions, basing it on
code from other parts of the API.
While I'm not a fan of file-by-file copyright inventory, as is used
here, I have added my copyright notice to this file alongside the
existing one, since I've made copyrightable changes to this file.
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.
The indentation style of this test file should match that of other
indentation in other tests.
I've also herein added Emacs variable settings to make sure Emacs users
have the same style enforced.
I'm using Emacs to edit this file and wanted to be sure that I matched
the existing coding style in use in this file. I believe these settings
properly match the coding style for this file.
@oalders noted in patch review on a pull request:
> Looks like this might be left over from debugging?
And he was indeed correct. ;)
I've removed the use. Data::Dumper isn't used by this test.
@oalders suggests in a pull request comment:
> If we use autodie then we won't need to check for success on open().
I've made this change to accommodate that suggestion.
Currently, the {PII_Options} / {PaymentItems}[0]{Options} are a list of
empty strings. This is probably the incorrect behavior, which I'm about
to fix. However, I'm committing this test as-is since it passes against
the current code as it stands.
I've noticed that the PII_Options field doesn't seem to properly contain
the values it should. This is the beginning of a test file for what
PII_Options should contain.
The initial step here is to simply create one of my forms to create a
test transaction, and verify that the transaction has been created.
These tests verify a TransactionSearch for ProfileID, and also serve as
an example of the method to find subscriptions using that method.
I've also added to the test a creation of an HTML form that can be used
to create a transaction that will allow the test to pass. This is a
hack, not unlike the hacks existing in the tests now that ask for
pasting of a transaction ID. Long term, if someone wants to do the
work, using WWW:Mechanize or some other method for full automation of
these tests might be useful, but I think the generated HTML file is a
step forward from the cut-and-paste solution currently in use.
