You are browsing a read-only backup copy of Wikitech. The primary site can be found at

Fundraising/Internal Endpoints/End of year emails

From Wikitech-static
< Fundraising
Revision as of 22:42, 4 November 2021 by imported>Eileen
Jump to navigation Jump to search

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 regularly. 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 parallel queues that is not really in play. However, it still achieves 'something' - if you were to try to send an individual 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
OLD docs

This is a drupal module that sends an email at the beginning of every year to all donors who have a recurring donation showing all their donations from the previous year.


There are three scripts, one to set up the data for the year and two to send the emails.


This takes the year passed in and calculates the recurring information from them and puts it into the drupal db table '''wmf_eoy_receipt_donor.'''

When running this in 2021, it caused the civi UI to be slow as well as deadlocks for any running jobs.


This sends half the emails through frmx1001


This sends the other half of the emails through frmx2001

'''How to Run'''

# There is a drupal variable to set [find the link] for the year you want the module to run for. This is used as the {year} variable in the content of the email sent.

# Clear out the previous years tables in the drupal db '''wmf_eoy_receipt_donor''' and '''wmf_eoy_receipt_job'''

# Turn off all the jobs and notify any civi users that the UI will be slow while the calculate job runs

# Run eoy_receipt_calculate. This only needs to be run once then everything in in the table for the email sends.

# Turn the jobs back on

# Test sending a receipt with slow start

# Turn the main sending jobs on