You are browsing a read-only backup copy of Wikitech. The primary site can be found at wikitech.wikimedia.org
Fundraising/Internal Endpoints/End of year emails
We send a letter for recurring donations once a year rather than as each donation is received. The code to do this is currently in 2 places (being consolidated to 1)
- drupal module wmf_eoy_receipt (old)
- civicrm_extension wmf-thankyou (new)
The code was written to bulk receipt recurring donations but a user-requested feature was added to support sending from the UI for a single donor. This UI feature is accessible from the actions menu (bottom right) from the contact summary screen.
The bulk jobs are to be scheduled - the idea is that there are 2 jobs
- `drush @wmff wmf-eoy-calculate-summaries --year=2021` (being changed to `drush @wmff cvapi EOYEmail.MakeJob version=4 year=2021` ) should be run just once. It populates a `wmf_eoy_receipt_donor` with basic details for all the emails sent and assigns them a job number, recorded in `wmf_eoy_receipt_job`. This job number is then an input into the second job.
- `drush @wmff wmf-eoy-send-letters --job_id=x` should be scheduled to run regularlay. It picks up the rows from the `wmf_eoy_receipt_donor` table with a status of queued & the relevant job id, sends them an email and updates them to 'sent'
The jobs can be called together with a 3rd drush command ` drush @wmff wmf-eoy-receipts --year=2021` - this probably only makes sense in dev environments
What is the point of the job number
The job number survives from some very old code. I think the thinking behind the job number was around a degree of batching and maybe paralel queues that is not really in play. However, it still achieves 'something' - if you were to try to send an indvidual receipt out from the UI then the send part of that action needs to only pick up that contact - or else it would send to the next x in the queue rather than that 1 contact, while the user waits.
What is changing
- consolidating all the code into the extension
- switching from twig to smarty
- moving the templates into the database
- using api actions rather than drush commands as part of drupal module decommissioning