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 another codebase, 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 asstudent_inactivity_reminder similar to the existingattendance_warning and introduce HAML a template underhttps://github.com/codebar/planner/blob/master/app/views/member_mailer/

We'd also need to schedule the notifier. This is done inlib/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 toapp/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

This implementation 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 casemember. 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: trueend

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  endend