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

Which invitation a dual-role member receives is decided by pass order, not product intent

Abierto
#2,902 1 comentario 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Activo
Stack tecnológico
ruby
Área
backend

Línea de trabajo

Empieza con el PR #2867 y el flujo de invitaciones en find_or_create_invitation. Lee Admin::InvitationController, Event#verified_students y Event#verified_coaches para entender cómo se mantienen los estados role, verified y attending al cambiar de rol. Product debe decidir primero qué invitación gana y si los cambios de rol restablecen el estado; terminado significa que el comportamiento elegido está implementado y protegido por las specs existentes.

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

Descripción

Summary

PR #2867 made (event/workshop, member) the invitation identity, so a member subscribed as both student and coach now receives exactly one invitation and one email. Which email that is depends on the invitation pass order: Coach first for events, Student first for workshops. The order is an implementation detail, not a product decision.

The specs in PR #2867 pin the surviving role and email subject, so a pass reorder cannot flip this silently — but if product wants, for example, the coach email to always win, that is a separate change.

Decision needed

For a member with both roles, which invitation should win?

  1. Keep pass order (current behavior: Coach for events, Student for workshops)
  2. Coach email always wins
  3. Student email always wins

Related: cleanup of existing duplicate rows (see companion issue), where the same "which one survives" question applies to historical rows.

Related design call (from the PR #2867 review): verified/attending state across role flips

The role flip carries verified and attending state across roles. Admin::InvitationController sets verified: true per row, and Event#verified_students / Event#verified_coaches select by role + accepted + verified. Consequence: a verified Coach invitation flipped to Student (via the self-RSVP role-choice-wins path in find_or_create_invitation) counts in verified_students with no admin action, and the coach-side verified record is gone. Under the old two-row design, verification stayed per role.

If product picks option 1 above (pass order), this needs no action. If product picks option 2 or 3, the flip direction should also decide whether a role change resets verified (and possibly attending).

Flagged by the ce-code-review run on PR #2867 (adversarial + correctness reviewers, confirmed by validation).

Lenguaje dominante
Ruby
Estrellas
104
Forks
205
Merge medio
1 d 8 h
PR fusionados (30 d)
67

Guía de contribución

Abrir la guía de contribución

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 codebar/planner

Todos los issues de codebar/planner

Issues similares

Más issues de Ruby

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.