Scheduled/triggered emails

[jonodrew]

@KimberleyCook has added a set of issues (#2386 , #2385 , #2384 , #2383 ) that all require some kind of automated emailing. They'll also require some kind of saved state - they can't all be triggered by an event.

I'm going to use this discussion thread to discuss how we might do this, and open it up to ideas from colleagues

[octoberclub]

Hi @jonodrew thanks for opening the discussion up.

I'm interested in contributing. My team have implemented similar capability elsewhere. Maybe there's many ways to achieve it and curious to find out other people's ideas or experience in this area. I'm only 2.5 years into full time Rails development and this is my first delve into the codebar codebase so forgive me if I'm missing some context of the current planner app. The ideas below come from a mixture of working on my current codebase at work, and some help from Codex AI helping guide me on the parts of the code that are already implemented

ActionMailer implementation

We already have mailers for various events
WorkshopInvitationMailer
VirtualWorkshopInvitationMailer
EventInvitationMailer (confirmation + includes .ics attachment)
MeetingInvitationMailer
MemberMailer (covers various meeting RSVPs, confirmations, wait-list approvals, and reminders)
FeedbackRequestMailer
ContactMailer (sponsors notification)

The approach for automated emailing might be to reuse the existing MemberMailer by adding new reminder actions such as student_inactivity_reminder similar to the existing attendance_warning and introduce HAML a template under https://github.com/codebar/planner/blob/master/app/views/member_mailer/

We'd also need to schedule the notifier. This is done in lib/tasks/reminders.rake, but we could add a members.rake perhaps?

Then we need some query to detect students to notify. We already have a class to extend here with the logic on who to send to app/models/invitation_manager.rb

Saved state ideas:

Simplest solution: Add a timestamp column

My first thought was to add a nullable timestamp on the members table for last sent e.g. last_inactivity_email_sent_at. It could be used to gate reminders and track when we last notified someone. The problem is as we build up the various email requirements for the notifications / reminders, we could find we have added too many columns. It might be the simplest change to allow us to check for when to trigger.

More flexible: Introduce a logger table

The implementation we have in use at my work makes use of an EmailLogger table which persists each email being sent, keyed by user and template. The mailer itself mixes in the EmailLogger concern, which runs an after_action once the email has been built. It records the rendered subject, body, and recipient lists in MemberEmailLogger, keyed to the resource that triggered the notification This can then be queried to discover last sent at by user, or in our case member. So in effect we've added a way of persisting information about sent notifications so we don't spam the members. It also gives us a handy audit trail if we need it. In our application we also surface the emails sent through the admin interface.

user_email_logger.rb

class MemberEmailLogger < ApplicationRecord
  belongs_to :member, polymorphic: true, optional: true
end

schema.rb

  create_table "member_email_loggers", id: :serial, force: :cascade do |t|
    t.integer "member_id"
    t.text "subject"
    t.text "body"
    t.text "to", default: [], array: true
    t.text "cc", default: [], array: true
    t.text "bcc", default: [], array: true
    t.datetime "created_at", precision: nil, null: false
    t.datetime "updated_at", precision: nil, null: false
  end

email_logger

module EmailLogger
  extend ActiveSupport::Concern

  included do
    after_action :log_sent_email

    private

    def log_sent_email
      return unless @resource

      MemberEmailLogger.create!(
        member: @resource,
        subject: mail.subject,
        body: mail.body,
        to: mail.to,
        cc: mail.cc,
        bcc: mail.bcc
      )
    end
  end
end