You are browsing a read-only backup copy of Wikitech. The live site can be found at wikitech.wikimedia.org

Fundraising/Internal Endpoints/End of year emails

From Wikitech-static
< Fundraising
Revision as of 21:16, 2 November 2021 by imported>Eileen
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
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 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'

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