Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Consolidate 'active' definitions: derive org status from affiliations, retire stored organization_status

Abierto
  • ¿Algo no está bien?
#2,068 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
38/100
Tipo de issue
Refactorización
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
ruby
Área
backend

Línea de trabajo

Lee app/models/organization.rb junto con app/models/organization_status.rb y app/models/affiliation.rb. Compara el scope active, el scope program_status, published? y el callback de sincronización de affiliation para definir la regla compartida facilitator-first. Se considera terminado cuando las rutas de lectura coinciden, mientras que el estado almacenado sigue siendo un fallback para las organizaciones sin historial de facilitator-affiliation; la reconciliación para una eliminación posterior se describe, pero no forma parte de esta unidad.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

database cleanup enhancement

Context

Organization#organization_status is a FK into the organization_statuses lookup table with six stored values: Active, Inactive, Pending, Reinstate, Suspended, Unknown. These are legacy, partly manually-set, and only loosely consistent with reality.

The maebeale/remove-org-status-columns branch took a non-destructive step:

  • Kept all six stored values. (An earlier commit added a destructive collapse migration; it was removed in 6cc9f6e41, never applied, no data lost.)
  • Added OrganizationStatus::PROGRAM_STATUS_BUCKETS, collapsing the six stored values into three display buckets: :active (Active, Reinstate), :formerly_active (Inactive, Suspended), :never_active (Pending, Unknown, none).
  • Reworked the Organization.program_status index-filter scope to prefer facilitator affiliations, falling back to the stored-status bucket only for orgs with no facilitator affiliations.

Problem: "active" is defined three inconsistent ways

Status is read three different ways, and they disagree:

  1. program_status scope (app/models/organization.rb:107) — affiliation-first: active facilitator affiliation ⇒ active; facilitator affiliations but none active ⇒ formerly active; no facilitator affiliations ⇒ stored-status bucket.
  2. active scope (app/models/organization.rb:70) — stored name == "Active" (exact string, so a stored "Reinstate" that buckets to :active is excluded) OR any active affiliation (Affiliation.active — any affiliation, not just facilitators).
  3. published? (app/models/organization.rb:279) — stored name == "Active" OR any active affiliation.

So "Reinstate" counts as active for the program-status chip but not for the active/published? scopes; and a non-facilitator active affiliation counts for active/published? but not for program_status. Separately, the affiliation.rb sync callbacks flip the stored status between "Active" and "Inactive" based on active facilitator affiliations — a fourth path that writes the very field the others partly ignore.

Goal

One source of truth for organization status, derived from affiliations, with stored organization_status retained only as a fallback for orgs with no facilitator-affiliation history — and eventually retired.

Options

A. Ship the current branch as-is. Non-destructive, data-safe, program-status UI reads correctly. Leaves the three-way inconsistency. Fine as an incremental step; not the endgame.

B. (recommended next) Unify the read paths. Rewrite the active scope and published? to use the same affiliation-first rule the program_status scope already uses (facilitator affiliations win; stored bucket is fallback). Result: one definition of "active"; stored status only matters for affiliation-less orgs. No data migration; reversible.

C. Retire organization_status entirely (long-term). Only after B is proven against real data. Snapshot each org's stored value into a flat organizations.legacy_status string first (frozen audit record), then drop the FK, the organization_statuses table, the sync callbacks, and the bucketing constant. The snapshot is the only way to later audit "what was this org before" — do not skip it.

Recommendation

Ship A now (already done and safe) → do B as the next unit of work → hold C until B has run against real data and the mismatches are reviewed.

Decided against

Backfilling placeholder Facilitator affiliations onto every stored-"Active" org to force the derivation to agree. Rejected: it fabricates evidence, requires a mandatory placeholder Person per affiliation, and is unnecessary — the fallback-to-stored-status path already keeps those orgs reading as active without inventing data.

Reconciliation to do before C

Because the stored status was partly manual, some orgs' stored value won't match what affiliations imply (the org form already warns "Does not match affiliations status"). Before dropping the field, list and review these — especially stored Suspended/Pending orgs that would derive as active — so real signal isn't lost.

Key references

  • app/models/organization_status.rb — PROGRAM_STATUS_BUCKETS, program_bucket, names_for_bucket
  • app/models/organization.rb — active scope (:70), program_status scope (:107), published? (:279), program_status method (:253)
  • app/models/affiliation.rb — sync_organization_status_with_affiliations (:122+), facilitators scope / facilitator?, FACILITATOR_TITLE

🤖 Drafted by Claude.

Lenguaje dominante
Ruby
Estrellas
15
Forks
28
Merge medio
1 d 12 min
PR fusionados (30 d)
262

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de rubyforgood/awbw

Todos los issues de rubyforgood/awbw

Issues similares

Más issues de Ruby

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.