InvitationManager silently no-ops on non-invitable events/workshops while controllers flash success
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 3/5
- Tiempo estimado
- 1-2 días
- Aptitud para principiantes
- 72/100
Línea de trabajo
Start at Admin::WorkshopsController#invite and Admin::EventsController#invite, then trace the three InvitationManager methods and their handle_asynchronously calls. Confirm that non-invitable targets produce a warning without enqueueing, while invitable targets retain the current success flow and email behavior.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Problem
Three InvitationManager methods guard with error strings — send_event_emails, send_workshop_emails, send_virtual_workshop_emails all return 'The X is not invitable' unless x.invitable?. All three run via handle_asynchronously, so the return value is discarded by the DelayedJob worker. The controllers (Admin::WorkshopsController#invite, Admin::EventsController#invite) ignore the return anyway and flash "Invitations will be emailed out soon." unconditionally.
Net effect: when the target isn't invitable, nothing is sent and nobody learns — the flash lies.
Proposed change
- Check
invitable?in the controllers before enqueueing and flash a warning instead of the success message when it's false. (Raising inside the async method can't fix the flash — the raise happens after the redirect.) - Remove the now-dead string returns from
InvitationManager; the internal batch-abort strings (start_invitation_batch→return result if result.is_a?(String)) may stay as internal control flow — implementer's call.
Acceptance
- Inviting to a non-invitable event/workshop shows a warning flash and enqueues nothing.
- Inviting to an invitable one behaves as today.
- Lenguaje dominante
- Ruby
- Estrellas
- 105
- Forks
- 206
- Merge medio
- 1 d 3 h
- PR fusionados (30 d)
- 74
Preparar el entorno
- Incluye un Dockerfile o un archivo de Docker Compose
- Sin plantilla de pull request
- Leer la 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
-
DashboardQuery eager-loads workshop_host with :sponsors in one join (same host-loss trap as #2975)Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día
-
enhancement
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
Los mantenedores suelen responder en 1 día
-
Dificultad 4/5 3-5 días Aptitud para principiantes 30/100
Los mantenedores suelen responder en 1 día
-
Dificultad 3/5 1-2 días Aptitud para principiantes 45/100
Los mantenedores suelen responder en 1 día
Todos los issues de codebar/planner
Issues similares
-
Add Catalan (ca) translationAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
eurosky-social/eu-haul#32 ·
-
good first issue
Dificultad 2/5 1-3 horas Aptitud para principiantes 85/100
benbalter/jekyll-relative-links#137 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
rubys/roundhouse#444 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 90/100
sclorg/s2i-ruby-container#656 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día