Add downloadable receipt for paid bulk payments - #2011
Conversation
84961a2 to
318399f
Compare
jmilljr24
left a comment
jmilljr24
left a comment
There was a problem hiding this comment.
The receipt doesn't reflect who paid, it's showing who submitted the form. I don't know how critical it is, but I could see someone getting their receipt with wrong payer info and wanted it fixed.
Do we actually need a name/org on the receipt? Invoice makes sense but the receipt is completely transactional. This amount was paid to awbw for xyz. But I don't know if some business (payer) needs so see their name on a receipt.
|
Also, being that the receipt is generated based on the event details, if a payment is made when an event is $1500 the receipt reflects that. If the event cost were to change (unlikely but out of principle) then receipt would then be updated. Shouldn't a receipt be static and captured at the time of payment? |
| payer_name = [ answers["payer_first_name"], answers["payer_last_name"] ] | ||
| .map(&:presence).compact.join(" ").presence || payer&.full_name | ||
| quantity = [ submission.bulk_payment_attendee_count, 1 ].max | ||
| amount_paid_cents = payment&.amount_cents.to_i |
There was a problem hiding this comment.
@jmilljr24 the receipt is based on amount paid, not amount of event cost. is this what you were concerned about wrt the comment re it being snapshot in time vs dynamic as event cost changes?
|
@jmilljr24 yes, i do think the org should be on the receipt |
|
🤖 From Claude: Fixed in 93eb27d — the receipt now bills the connected payment’s payer (respecting |
93eb27d to
171fd44
Compare
Bulk payers had only an invoice. Once a payment is on file they now get a receipt (proof money changed hands) from the ticket's Documents section, and a locked card until then. The receipt bills whoever the connected Payment records as the payer (respecting payer_type) — not the form submitter, who can differ once an admin records the payment against a different person/organization. A bulk payment has no owed-balance/paid-in-full concept, so the shared receipt document (EventReceipt#settles_balance?) shows just "Amount paid" + "Payment received" for bulk payments, keeping the "Total charged / Balance due / Paid in full" reconciliation for registration receipts. Rebased onto main's split of the bulk payment controller: the payer-facing receipt action lives on BulkPaymentFormSubmissionsController and authorizes via FormSubmissionPolicy#receipt? (slug context), matching #ticket. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The bulk invoice was served by InvoicesController#show via submission_id, with FormSubmissionPolicy#show_invoice? returning true for any bulk payment — so any payer's invoice (names, emails, org, attendees) was reachable by guessing a sequential id, weaker than the slug-gated ticket/receipt for the same record. Move it to a slug-based BulkPaymentFormSubmissions#invoice, authorized like #ticket/#receipt (admin? || slug matches), colocating all three payer documents on the payer-facing controller and mirroring RegistrationsController. Update the ticket, dashboard card, and submission-page links to the slug route. InvoicesController now serves only the admin blank template. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The payer invoice route is slug-only, but a submission whose role becomes bulk_payment after creation (or legacy records) can have a nil slug, so the admin form-submission page and dashboard card raised UrlGenerationError. Only render the invoice link when a slug is present — slugless legacy records have no payer-facing pages anyway. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
6f80e0a to
c107a79
Compare
🤖 suggested review level: 5 Inspect 🔬 payer-facing receipt + a security fix (invoice was reachable by enumerable id) + a Rails/blazer security bump
What & why
payer_type) — not the form submitter, who can differ once an admin records the payment against another person/org.EventReceipt#settles_balance?) shows just "Amount paid" + "Payment received" for bulk, keeping the "Total charged / Balance due / Paid in full" reconciliation for registration receipts.Invoice access hardening
InvoicesController#showviasubmission_id, withFormSubmissionPolicy#show_invoice?returning true for any bulk payment — so a payer's invoice (names/emails/org/attendees) was reachable by guessing a sequential id, weaker than the slug-gated ticket/receipt.BulkPaymentFormSubmissions#invoice, authorized like ticket/receipt (admin? || slug matches). All three payer documents now live on the payer-facing controller (mirrorsRegistrationsController).InvoicesControllerkeeps only the admin blank template. Ticket/dashboard/submission links updated to the slug route.Structure (rebased onto main's controller split)
BulkPaymentFormSubmissionsController, slug-authorized viaFormSubmissionPolicy.AllocationLedgerLabelrefactored to label aPaymentdirectly so invoice/receipt stay in sync.CI
rails8.1.3→8.1.3.1,blazer3.3.0→3.5.0) to clear repo-wide bundler-audit advisories published 2026-07-29 (activestorage CVE-2026-66066, blazer stored XSS) — unrelated to the feature; kept as its own commit.Tests
FormSubmissionPolicy#invoice?/#receipt?specs. RuboCop clean.