Skip to content

feat: Newsletter signup checkbox in donation form creates Redis entry

stephen requested to merge newsletter_signup-initial_wiring into main

The newsletter signup checkbox on the donation form has, up until now, done nothing; this is due to the fact that Redis needed to be connected to the staging server first, because all of the newsletter operations rely either on using Redis for transient key-value pair storage, or on using Resque (via Redis) to send commands and signup data to CiviCRM, where newsletter signups are properly recorded and managed.

This MR contains the first step towards this functionality, and not much more; checking the "Send me updates from the Tor Project" box on the donation form will now, once the form is validated but before the donation transaction is processed, create a unique key-value entry in Redis, with the key reading "subscription_request:[unique random ID]" and the value being a string representation of a dict containing an email address and a first and last name. This key-value pair is then given an expiration timeout of one hour.

In its complete implementation, the donating user would thereafter receieve a followup email with a specially-prepared link, and said link would check the Redis database for our specific key. Upon finding an unexpired matching key, the subscription process would continue.

There are a few reasons why this MR is being submitted in this state, rather than a more fully-implemented state:

  1. The old donate site used a PHP library to generate and send email directly to the donating user. It is probable that the containerized way in which donate-neo is being served is antithetical to sending email, or that there are drawbacks to doing so which may not have been present in the PHP implementation of same.

  2. CiviCRM itself contains an entire mailing system - it is, in fact, what actually prepares and sends newsletters via email. If there is a method by which these emails could be sent via CiviCRM, it might be better to do so, especially now that we can send Resque messages directly to CiviCRM staging.

  3. There is a desire to have the staging server instance of donate-neo capable of updating its connected Redis database from the front-end; multiple contributors to the project have asked for this functionality for their own testing and development purposes. Implementing the newsletter functionality up to, and no further than, the point at which it writes to Redis, serves two purposes:

3a. It moves the newsletter functionality forward, and 3b. It provides a way for test users to update the Redis database from the staging server's front-end

Other methods of providing "proof-of-life" Redis connectivity would have either required more up-front development, or development that would be thrown out (in part or in full).

Future MRs will, naturally, expand upon this functionality.

Merge request reports