rubyforgood / rubyforgood/awbw

Auto-capture + backfill TopicSubscriptions from the registration form's interested_in_more answer

Open
#2,079 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement
Dominant language
Ruby
Stars
15
Forks
26
Avg merge
12h 42m
Merged PRs (30d)
242

Description

Follow-up to #2070 (introduces TopicSubscription / TopicSubscriptionType).

Problem

The registration form's interested_in_more answer ("Are you interested in learning more about upcoming trainings or resources?") still drives nothing — it's stored only as an inert FormAnswer. And historical answers aren't backfilled into subscriptions. The target topic is already defined: TopicSubscriptionType::INTERESTED_IN_MORE_KEY = "facilitator_trainings".

Scope

  1. Capture on submit — when a public/admin registration is submitted with interested_in_more: Yes, create (or reactivate) an active TopicSubscription for that person on the facilitator_trainings topic, with a traceable source (mirroring the record_mailing_list_consent provenance, e.g. "2026-08-03 Facilitator Training registration"). Idempotent — don't create a duplicate active subscription (the model already enforces one active per person·type·event).
  2. Backfill migration — walk existing FormAnswers for interested_in_more == Yes and create the corresponding subscriptions, preserving the original registration date as subscribed_at.

Notes / open questions

  • Resolve the canonical type via the stable key (TopicSubscriptionType.interested_in_more); guard for the type not existing (e.g. before seeds run).
  • Confirm whether a No answer should do anything (likely nothing).
  • Consent is separate: capturing interest ≠ mailing_list_consent. Don't conflate.
  • Decide whether general (interested_event: nil) is correct here, or whether to narrow to the registration's event.

Blocked on #2070 merging (or can build on that branch).

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reviewing #2070 and the TopicSubscription and TopicSubscriptionType models, then trace public/admin registration submission and the existing record_mailing_list_consent provenance. Inspect FormAnswer records and the migration path before deciding how to handle missing types, No answers, and event scope. Done means idempotent capture and a backfill preserving the original registration date without conflating interest with consent.

Written by the indexing model from the issue text.

Assessment

Tech stack
ruby
Domain
backend, database
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.