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.
This should succeed as the previous tests show. They now pass:
ok 21 - addEmailAddress: fails adding existing email address with mismatched type.
ok 22 - addEmailAddress: succeeds when adding email that already exists...
ok 23 - addEmailAddress: ... and returns same id.
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.
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.
This is the location where there was unbalanced _beginWork()/_commit()
calls. In future, when writing tests, it's probably good to check this
often in the tests.
These tests now pass:
ok 106 - setPreferredEmailAddress: dies for undefined id
ok 107 - setPreferredEmailAddress: dies for non-numeric id
ok 108 - setPreferredEmailAddress: email address undefined fails
ok 109 - setPreferredEmailAddress: email address with extra @ fails to add.
ok 112 - setPreferredEmailAddress: email address not found in database does not die....
ok 113 - setPreferredEmailAddress: ....but returns undef
ok 116 - setPreferredEmailAddress: setting preferred email address succeeds....
ok 117 - setPreferredEmailAddress: ... and returns correct email_address_id on success
of course, getRequest() returns a hash so we must properly extract the
value we want.
This fix causes this test to now pass:
ok 73 - fulfillRequest: databse entry from successful return is correct
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.
addRequest-specific unit tests now all pass:
ok 55 - addRequest: dies if supporterId not specified.
ok 56 - addRequest: dies if requestTypeId / requestType not specified.
ok 57 - addRequest: dies if supporterId invalid.
ok 58 - addRequest: dies if requestTypeId invalid.
ok 59 - addRequest: succeeds with a requestType but no configuration parameter.
ok 60 - addRequest: id returned on successful addRequest() is a number
ok 61 - addRequest: underlying call to addRequestType works properly, per getRequestType
ok 62 - addRequest: succeeds with a requestType and requestConfiguration and a note.
ok 63 - addRequest: succeeds with a requestTypeId and requestConfigurationId with no a note.
The older transaction counter was for the whole class, which was
problematic if you had more than one supporter database open at a time,
or were otherwise using different supporter databases.
I'm not completely sure this fix is fully functional, because perhaps we
should be carrying this counter along with the DBH (i.e., what if two
Supporter instances are created with the same dbh).
I suppose we could fix this problem by changing the new() interface to
require the instance itself be in control of the dbh.
There was some parameter confusion (using ids instead of the actual
types/descriptions) on some of the public facing methods.
Also, lookup of existing ids was buggy; just use public facing methods.
