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.
It seems that date('now'), at least in sqlite, is in UTC. So, we want
the tests to match that.
There are still timing bugs possible here, but with this change, they
should only occur if you run the test right at 23:58 or 23:59 UTC. :)
We don't really need lookup based on requestTypeId for this anyway, so
this method really only needs two arguments (perhaps a third optional
argument to be added later).
Parameter check tests now pass:
ok 66 - fufillRequest: dies if supporterId not specified
ok 67 - fufillRequest: dies if supporterId not found in database
ok 68 - fufillRequest: dies if requestType not specified
ok 69 - fufillRequest: who not specified
Also added new test.
This test now started failing after the other corrections made in the
last few commits.
As it turns out, this test was buggy. We wanted to test a request_type
that didn't exist, and verify that calls to addRequestConfigurations
with bad arguments didn't create the request_type if it didn't already
existed. That's what the test now does.
These tests mostly fail, although a few pass automatically:
not ok 26 - addPostalAddress: dies for undefined id
not ok 27 - addPostalAddress: dies for non-numeric id
not ok 28 - addPostalAddress: postal address undefined fails
ok 29 - addPostalAddress: type is not added when other input paramaters are invalid
ok 30 - addPostalAddress: addPostalAddress of a valid formatted_address works.
ok 30 - addPostalAddress: addPostalAddress of a valid formatted_address works.
not ok 31 - addPostalAddress: id returned is sane.
Goal is to implement those and make sure they all pass.
Now that we are properly nesting transactions, this test is shown to be
incorrect. Namely, it is indeed correct that the entire add should fail
when we've given something invalid: we don't want to add the requestType
if it wasn't already there if the parameter to add
addRequestConfigurations was invalid.
This new section of tests verifies that when the database disappears
underneath or has other types of problems that the API still functions
as expected.
The second test committed herein currently fails.
A basic implementation of getRequestConfigurations and tests to go with
it.
Also added here is the test to verify that no items are added when
duplicates are included.
Adjusted one test slightly: there was a missing argument. Also,
corrected test count.
While implementing, I realized a failure mode that forces a rollback:
duplication on the input list of configurations. Tests are now needed
for that.
