Requests on hold can never be fulfilled.
If you want to fulfill a request that is currently on hold, the right
semantic is that you should remove the hold, then fulfill the request.
Note that this test now passes and it didn't before:
fulfillRequest: .... but undef is returned when attempting to fulfill a held request.
It's clear from the Supporters.pm code that when an hold is attempted on
an already held request, it simply returns the id of the existing hold.
I don't actually remember what behavior I really wanted here. There are
certainly possibility for semantic confusion in the API with the current
functionality, since the API caller must actually check to verify if the
hold they got is a new one or just an existing one.
Perhaps this should be rethought. I left a comment in the test code for
that reason.
This change better handles the situation where t-shirt-0 and t-shirt-1
are requested and owed to the same donor. We've added even more t-shirt
request types at this point meaning many shirts can go to one donor, and
this change should better handle that situation.
This change, which is not properly documented nor tests present, adds
support for making sure those who don't want emails from us do not
receive them.
I believe I've caught most of the places we want this change supported.
This allows adding a .tex file and sending a paper renewal notice.
This worked for me to send the paper renewal notices to Conservancy
Supporters in late 2016.
if we are unable to fulfill a request, this method turns it into an
indefinite hold on the request.
This design model for handling failure in fulfillment may not be the
best one, but it seemed to roughly fit the behavior and data model we're
looking for.
A little information is lost, but is at least saved in the 'why' field
of the request_hold table.
Requests can now be placed "on hold", and getRequest() can ignore held
requests.
This required addition of a table, and another API call holdRequest().
Tests were not written here, which was a mistake. Unit tests and docs
are needed. A FIXME was added, at least.
Also, minor imporvements to reporting on fulfilled requests.
This code worked reasonable well when there was only one type of renewal
notice in play for a long period of time, but the point here is that we
can have many of them and this script should handle sending out the
different ones at different types.
We probably need an entirely separate script to intuit response.
We actually can't rely on a call to $sp->findDonor({}) to give us *just*
Supporters, as eventually, this may be a donor database too. So, count
them.
Really, $sp->findDonor() should be able to take { isSupporter => 1 }
instead.
