I debated whether to create a getRequestTypes() instead, but this seemed
reasonable. I am too far out of Perl5 programming culture to know if
this sort of interface is recommended practice.
First of all, I originally thought about releaseDate all wrong. We want
to store the date that the hold was released, which is the indicator
that the request is no longer on hold and can be fulfilled.
We also need tests that assure a request is not fulfilled while on
hold. Those are added here.
I shook out a few other changes to the test ordering that are necessary
for the change to testing holdRequest().
The ledger data can, in fact, sometimes have a missing entityId for
various reasons. For now, these donations should just be ignored.
Perhaps in future a warning of some sort should be generated.
These two new tests:
ok 222 - supporterExpirationDate(): same donation amount in year...
ok 223 - supporterExpirationDate(): ...returns the latter date.
did not pass without this change. The list for annuals in
supporterExpirationDate() was sorted in the wrong order, producing
erroneous results.
Since the emailAddress criterion could find more than one entry, this
change has findDonor returning a list rather than a scalar integer and
thus finding multiple items are ok.
Tests are more extensive now that this API change is in effect.
Instead of a bunch of serial arguments, reimplement getRequest() to take
a hash of parameters.
In the process, add support for requestTypeId to be included.
I found need to have _verifyRequestTypeId() actually return the
request_type in a reimplementation of getRequest() that I'm working on,
so I've made this change. Some tests are failing because of the use of
_verifyRequestTypeId(). Next commit will address that.
Since we converted to making this a more general donor database, change
the handle used for an individual in the database from supporterId to
donorId.
Note that I left addSupporter() method name untouched because it does
automatically assume you mean a supporter, not a mere donor. Later, an
addDonor() method should likely be added.
Up until now, this software has been focused on just Supporters, but
really there is no reason this should not be a general donor database.
Therefore, don't use the name supporter in the database, and add a
field.
public_ack is now allowed to be NULL, because the idea being we don't
have an answer from all who donate whether or not they want public
acknowledgment.
the is_supporter boolean is added to record whether or not they came
through the supporter program.
