Transferred-in ticket: surface source financials and service them from the new registration
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 48/100
Línea de trabajo
Después de que se integre #2044, empieza en EventRegistration e inspecciona los métodos existentes de delegación transferred_in? y el partial de source financials. Después, sigue el recorrido de app/views/events/callouts/payment.html.erb, Events::CalloutsController, Events::RegistrationsController, event_invoice.rb, event_receipt.rb, builtin_callout_cards.rb y pay_charge_extensions.rb. Añade specs de modelo y de request para source-payment delegation, scholarship servicing, payment-page rendering y pay routing; luego ejecuta ai/test_extra. El trabajo está terminado cuando los source-held payments y las scholarships se gestionen desde el nuevo ticket sin registrar los payments incorrectamente.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Followup to the event-registration transfer work (#1944 / PR #2044). Start as a new branch off main after #2044 merges — not part of #2044.
Context
A transferred-in registration's registrant-facing ticket/callout pages don't correctly surface or service the money/scholarship that live on the source reg. The read-side "amount due" already delegates to the source; the gaps are the payment ledger, scholarship servicing, and a pay-flow that misfiles a payment onto the transferred-in reg without clearing the delegated balance.
Caveats (main moved since this was drafted):
- Line numbers below are approximate —
mainadvanced through #2237/#1993/#2178/#2258, so verify against current code (method names are stable).- #2178 (scholarship decline flow) is now merged and reworked the scholarship agreement into a tri-state
agreement_response_status(pending/accepted/declined) +ScholarshipAgreementResponsehistory. Part 2 (scholarship servicing) must be built against that new model, not the oldagreement_signed_atboolean.
The governing rule
Delegation to the source is conditional on the source actually having allocations/payments.
- Source has payments → the financial record is anchored on the source. Show the source's ledger + delegated balance on the new ticket; to pay a remaining balance, send the registrant to the source reg's ticket (pay there, allocations stay on source). Never let a payment land on the transferred-in reg in this case.
- Source has no payments → the math should all be on the new reg. The new reg owns its own cost/balance/allocations; the registrant pays on the new reg normally (no delegation). This also removes the misfiling risk.
Implementation seam: gate the existing transferred_in? delegation in EventRegistration (remaining_cost, paid_in_full?, payment_received?, payment_access_granted?, invoice_available?, etc.) on transferred_from_registration.allocations.exists? (or payments_sum.positive?). Add a predicate like source_holds_financials? = transferred_in? && source.allocations.exists? and key the delegations + the pay routing off it. Verify the invoice/receipt from_registration swap (app/presenters/event_invoice.rb, event_receipt.rb) respects the same condition.
Part 1 — Payment ledger
app/views/events/callouts/payment.html.erb (+ payment action, Events::CalloutsController):
- Keep this reg's own allocations rendering as-is (the existing
@allocationslist). - If transferred-in AND the source has allocations, add a separate section below — "Payments on your original registration" — rendering
source.allocations. Reuse the figures the admin summary already computes inapp/views/event_registrations/_transferred_in_financials.html.erb(source.event.cost_cents,source.allocations_sum/payments_sum, due). - "Amount due" already correct via delegated
remaining_cost— leave it, but it now follows the conditional-delegation rule.
Part 2 — Scholarship servicing
Let the registrant view + respond to the source's scholarship from the new ticket, showing the old reg's scholarship record.
scholarshipaction gate +@scholarship: resolve via the chain —EventRegistration#effective_scholarship(scholarships.first || transferred_from_registration&.effective_scholarship) instead of raw@event_registration.scholarships.first. Relax the gate so a transferred-in reg whose source has a scholarship isn't redirected away.sign_agreement(and the new accept/decline flow from #2178): operate on the source's Scholarship record (same person).scholarship_status_cardbuilder (app/services/builtin_callout_cards.rb): use the effective scholarship for the card's gate + data.- Task completion stays admin-only (display only).
- The scholarship view's admin "Edit scholarship" link should point at the source's scholarship record.
Part 3 — Pay-flow correctness
payaction +redirect_to_stripe_checkout(Events::RegistrationsController) and the webhook allocation (pay_charge_extensions.rb): whensource_holds_financials?, route the checkout/allocation to the source reg (metadataevent_registration_id= source), so paying clears the delegated balance. When the source holds no financials, the transferred-in reg pays itself (correct onceremaining_costno longer delegates in that case).- On the ticket/payment page, the pay button for a transferred-in reg with a source balance should link to the source's payment/ticket rather than posting to its own pay path.
Per-builtin (no change needed)
- ce_hours — correct (hours ride on the new reg's own record).
- certificate — correct (earned at the intended/new event).
- videoconference / staff / handouts / faq — correct (this event's content); keep showing (they're attending here), unlike a transferred-out reg.
- art_supplies — reserved key, unused; ignore.
Verification
- Model specs for conditional delegation: transferred-in with source payments → delegates; with no source payments → own math.
- Request specs: payment page shows the source-allocations section only when transferred-in + source has allocations; scholarship page renders + services the source's scholarship from the new slug; pay routing targets the correct reg.
ai/test_extrabefore opening the (draft) PR.
🤖 Filed by Claude for maebeale — followup to #1944.
- Lenguaje dominante
- Ruby
- Estrellas
- 15
- Forks
- 28
- Merge medio
- 1 d 12 min
- PR fusionados (30 d)
- 262
Preparar el entorno
Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.
- Incluye un Dockerfile o un archivo de Docker Compose
- Tiene una 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 rubyforgood/awbw
-
blocked
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
rubyforgood/awbw#2824 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
rubyforgood/awbw#2822 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
rubyforgood/awbw#2160 ·
Los mantenedores suelen responder en 1 día
-
Update callout faq defualt text when the new person subscription launchesPosiblemente ocupada @maebeale la tomó hace 77 días. Abiertoblocked
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
rubyforgood/awbw#2095 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
rubyforgood/awbw#2088 ·
Los mantenedores suelen responder en 1 día
Todos los issues de rubyforgood/awbw
Issues similares
-
Liens externes cassésAbierto
Dificultad 1/5 1-3 horas Aptitud para principiantes 66/100
betagouv/conseillers-entreprises#4770 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 85/100
seek4science/seek#2762 ·
Los mantenedores suelen responder en 5 días
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
rubyevents/rubyevents#2277 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 1/5 1-3 horas Aptitud para principiantes 92/100
Los mantenedores suelen responder en 2 días