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.
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.
