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.
In an effort to improve the formatting on outgoing emails from the
renewal script, add the display_name to the To: field.
I'm not completely happy with what the MIME encoding is doing here.
Specifically, it chops the line on the < of <email@example.org> so you
get this:
"A very long name that leads to wrapping of the MIME encoded line" <
email@example.org>
As I read https://www.ietf.org/rfc/rfc2822.txt, it violates this SHOULD:
Note: Though structured field bodies are defined in such a way that
folding can take place between many of the lexical tokens (and even
within some of the lexical tokens), folding SHOULD be limited to
placing the CRLF at higher-level syntactic breaks. For instance, if
a field body is defined as comma-separated values, it is recommended
that folding occur after the comma separating the structured items
in preference to other places where the field could be folded, even
if it is allowed elsewhere.
Brett and I decided to leave it for now and go with it.
The idea behind this sort is to give monthlies top priority based on
their id number (i.e., when they hit $60, just get that shirt out to
them), and for annuals, make sure we prioritize based on how long it has
been since their last donation.
The request date depends on the import date, not the date of the
donation, so we have to range-check here to see if it's nearby the date
of the last donation.
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.
