Which invitation a dual-role member receives is decided by pass order, not product intent
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 35/100
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?
- Keep pass order (current behavior: Coach for events, Student for workshops)
- Coach email always wins
- 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
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de codebar/planner
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
-
Dificultad 4/5 3-5 días Aptitud para principiantes 48/100
-
Clean up historical duplicate invitation rows (one member, two invitations per event/workshop) Abierto
Dificultad 5/5 Más de una semana Aptitud para principiantes 25/100
-
good first issue performance
Dificultad 3/5 1-2 días Aptitud para principiantes 78/100
-
enhancement good first issue
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
Todos los issues de codebar/planner
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
-
bug
Dificultad 1/5 Menos de una hora Aptitud para principiantes 90/100
riscv/riscv-unified-db#2626 ·
-
Component: GLib
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
-
ds-drift
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
we-promise/sure#3693 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
simp/pupmod-simp-simp#395 ·