Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Backfill contact_us_fyi communications as incoming, then drop the dual-condition checks

Aperta
  • Qualcosa non va?
#2,242 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
72/100
Tipo di issue
Refactoring
Chiarezza
Specificata chiaramente
Stato di attività
Tranquilla
Stack tecnologico
ruby
Ambito
backend, databases

Direzione di ricerca

Inizia da app/models/notification.rb, dal percorso di creazione di contact-form/NotificationServices e dalle specifiche di .responded_status e #requires_response? in spec/models/notification_spec.rb. Aggiungi la reversible backfill migration dopo aver confermato che le righe contact_us_fyi debbano essere incoming, aggiorna la creazione e le condizioni, quindi esegui le specifiche di Notification e verifica che il down path della migrazione sia protetto.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

database cleanup

Context

In #2239 we extended the "needs response" concept from contact_us_fyi notifications to all incoming communications. Because existing contact_us_fyi rows are stored as direction: "outgoing", the code currently has to check both conditions:

  • Notification#requires_response? — kind == "contact_us_fyi" || incoming?
  • Notification.responded_status scope — where(kind: "contact_us_fyi").or(where(direction: "incoming")), and the "na" branch has to exclude both.

A contact_us_fyi is conceptually an incoming contact (the person reached out to us), so it should simply carry direction: "incoming". Once it does, the kind == "contact_us_fyi" half of every check is redundant and can go.

Work

  1. Create new contact_us_fyi notifications as incoming. Update wherever they're generated (contact-form flow / NotificationServices) so direction: "incoming" is set on creation. Do this first — otherwise removing the OR breaks newly-created rows.
  2. Backfill existing rows — a reversible data migration: Notification.where(kind: "contact_us_fyi", direction: "outgoing").update_all(direction: "incoming") (guard the down).
  3. Simplify the code once every contact_us_fyi is incoming:
    • requires_response? → incoming?
    • responded_status → key off direction: "incoming" only:
      • "yes" → where(direction: "incoming", responded: true)
      • "no" → where(direction: "incoming", responded: false)
      • "na" → where.not(direction: "incoming")
  4. Update specs in spec/models/notification_spec.rb (the .responded_status and #requires_response? groups) to reflect the single-condition logic.

Notes

  • Sanity-check that no contact_us_fyi should legitimately be outgoing before backfilling.
  • Files: app/models/notification.rb, plus the contact-form/notification-creation path.
Lingua principale
Ruby
Stelle
15
Fork
28
Merge medio
1g 12m
PR unite (30g)
262

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di rubyforgood/awbw

Tutte le issue di rubyforgood/awbw

Issue simili

Altre issue su Ruby

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.