Remove unused unsubscribed column from members
I maintainer di solito rispondono entro 1 giorno
@mroderick ci sta già lavorando.
Dal 12/10/2026.
Valutazione
Questa issue non è ancora stata valutata.
Descrizione
Problem
The members.unsubscribed boolean column is dead and should be dropped. Nothing reads or writes it. It survives in db/schema.rb and in production data only.
Git history shows when it died:
- 2013-10-21 (
86bae547): migration20131021040356_add_unsubscribed_to_member.rbadded the nullable boolean,MembersController#unsubscribeset it totrue, and the invitation email carried the unsubscribe link. - 2014-03-29 (
bd0772a2):default_scope -> { where(unsubscribed: [false, nil]) }became the only read. - 2014-06-22 (
59df6c1c): that default scope was removed. Nothing has read the column since. - 2014-08-24 (
0cdd988a): theunsubscribeaction became a signed-token redirect to the subscriptions page. The write went with it. Nothing has written the column since.
Unsubscribing today runs through soft-deleted subscriptions (Discard, tombstones per #2920); the newsletter opt-in is tracked in opt_in_newsletter_at. The originating migration was deleted with the pre-2026 migration purge (fd7e972f).
Production data
The column still holds the 2013-2014 clicks (snapshot 2026-10-12): 84 true, 6 false, 29,576 NULL. All 90 non-null values belong to members created between 2013-10-21 and 2014-07-01. Of the 84 flagged members, 11 hold active subscriptions today and have received mail for years regardless of the flag, and 2 have opted into the newsletter since.
Recommendation: drop the column without changing any subscription state. The flag has been inert for over 12 years; acting on it now would apply decade-old intent over current state, including over the 2 later opt-ins. The counts above are the last trace of the feature.
Why the two-step removal is load-bearing
Production runs with Heroku preboot: the release phase runs migrations before new dynos boot, and old dynos keep serving against the new schema during the switch. Old releases build their member SELECT list from their schema cache and name every column explicitly (SELECT "members"."id", ..., "members"."unsubscribed", ...). Dropping the column while old dynos serve would fail every member query on them with PG::UndefinedColumn. Writes are not affected: partial_inserts keeps the nullable, default-less column out of INSERTs.
So the removal stays as proposed:
- Add
unsubscribedtoself.ignored_columnsonMemberand deploy. The column then drops out of the new release's SELECT list and out of the model's attribute methods. - In a separate deploy, wrap
remove_column :members, :unsubscribedinsafety_assured. strong_migrations 2.8 prescribes exactly this sequence.
Verification notes
- grep and ast-grep across
app,lib,config,spec,db: no code reference to the column. Matches are comments, locale strings, view prose and spec variable names only. - No migration in
db/migrate/references it. The originating migration was deleted infd7e972f. - No database views or triggers reference the column.
- The codebar auth app does not reference the column.
Member.all.to_sqlon master namesmembers.unsubscribedin the SELECT list; withignored_columnsset it does not.
- Lingua principale
- Ruby
- Stelle
- 105
- Fork
- 206
- Merge medio
- 19h 48m
- PR unite (30g)
- 83
Preparare l'ambiente
- Include un Dockerfile o un file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di codebar/planner
-
DashboardQuery eager-loads workshop_host with :sponsors in one join (same host-loss trap as #2975)Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
I maintainer di solito rispondono entro 1 giorno
-
enhancement
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 28/100
codebar/planner#3008 · 2 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 18/100
codebar/planner#3006 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di codebar/planner
Issue simili
-
NoMethodError in auth#createApertabugsnag
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
JoeMcB/improvcoaches#827 ·
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 72/100
TheOdinProject/curriculum#31465 ·
I maintainer di solito rispondono entro 1 giorno
-
area: docs eco: ruby good first issue help wanted lane: free-agent roadmap size: XS type: docs
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 66/100
arminazimi/evergreen#465 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 66/100
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 72/100
simp/puppetsync#120 ·
I maintainer di solito rispondono entro 2 giorni