Note my comment that the error messages don't work properly on NULL
values. I once in my life spent years wondering about how to handle
three-valued logic problems in SQL. I thought that part of my life
was apparently over, but I guess not. 🤷
The `UserOperation_fix_tshirt_size_request` view is designed to allow
end-users edit t-shirt sizes in the request using a program like
`sqlitebrowser`.
This is the first implementation attempt of a user operation that
allows changing the T-Shirt size.
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.
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.
The problem is that the supporter can have multiple non-preferred email
addresses.
I'd have to investigate if there's a way to make a UNIQUE key on a value
set to a specific value.
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.
Redesign of database, mainly for three reasons:
(a) we need to send renewal notices to Supporters, and need to keep a
record of when we've sent them,
(b) We need to keep better track of t-shirt requests,
(c) We need to allow for different email addresses for contact other
than the PayPal payer one.
Before doing this, I briefly looked again at CiviCRM. While I can
complete this conversion and all my scripts in just a matter of a few
hours, setup of CiviCRM would take a minimum of a few hours just to
investigate its viability for us and whether I'd be able to maintain it.
So, we're doing custom, ad-hoc stuff still.
This commit has not been tested, it's a first pass that I'll adjust.
Ultimately, I decided I had little choice but to create a database of
supporters. There is really no easy way to track all this properly with
ledger, since ledger is transaction based and this is data that spans
many transactions.
Indeed, even in the NPO Accounting project, we knew there would be
separate data stores for contacts, etc. This is an ad-hoc start to
that, I guess.
