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
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.
These tests now pass:
ok 110 - _getOrCreateRequestConfiguration: dies on empty hash
ok 111 - _getOrCreateRequestConfiguration: dies for string requestConfigurationId
ok 112 - _getOrCreateRequestConfiguration: dies for non-existant requestConfigurationId
ok 113 - _getOrCreateRequestConfiguration: dies for string request id
ok 114 - _getOrCreateRequestConfiguration: dies for non-existant requestTypeId
Basic implementation of addRequest, which causes these test to now 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 61 - addRequest: underlying call to addRequestType works properly, per getRequestType
Tests pass for this now:
ok 97 - _getOrCreateRequestType: dies on empty hash
ok 98 - _getOrCreateRequestType: dies for string request id
ok 99 - _getOrCreateRequestType: dies for non-existant requestTypeId
ok 100 - _getOrCreateRequestType: succeeds with just requestType
ok 101 - _getOrCreateRequestType: lookup of a request works after _getOrCreateRequestType
ok 102 - _getOrCreateRequestType: lookup of a request works after _getOrCreateRequestType
ok 103 - _getOrCreateRequestType: lookup of existing requestType suceeds.
ok 104 - _getOrCreateRequestType: deletes requestType if both are provided.
All tests related to addPostalAddress now pass.
ok 28 - addPostalAddress: dies for undefined id
ok 29 - addPostalAddress: dies for non-numeric id
ok 30 - addPostalAddress: postal address undefined fails
ok 31 - addPostalAddress: type is not added when other input paramaters are invalid
ok 32 - addPostalAddress: addPostalAddress of a valid formatted_address works.
ok 33 - addPostalAddress: id returned is sane.
Upon fixing the reference counter thing in the previous commit, this bug
caused tests to fail. We have to _rollback() properly any time we've
called _begin_work(), particularly before die()'ing after a
_begin_work().
This code was clearly not correct as it was. The main problem is that I
was envisioning begin_work/commit pairs as always matched, but of course
if we die in the middle of a transaction, the counter has to be reset.
That's why we have to set the $dbh->{HandleError} in new() to a
subroutine that does that.
Also, we need to similarly wrap rollback() calls. When rolling back, we
have to reset the counter as we're not going to commit() (that's the
point).
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.
Properly map email address to supporter when email address is added.
Test now passes:
ok 12 - addSuporter: email address mapping is created on addSupporter() w/ email address included
All of the addSupporter must now succeed (including sub-operations like
addEmailAddress).
This causes one failing test to now pass:
ok 55 - addSupporter: fails if email_address given but email cannot be inserted
I want to be able to nest begin_work()/commit() calls. Years ago (in
the mid-1990s), when I did database programming, this is how we handled
this scenario. I have no idea if there is now a "better way" to do
this, but some quick net searches found nothing that is recommended, but
I admittedly didn't search that hard.
This should work for our needs.
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.
