Capture bulk payment attendee registrant link - #2018
Conversation
|
ooo! i really like that 2-step UI! makes it so much clearer what is happening. |
| @form_fields = visible_form_fields | ||
| @event = @event.decorate | ||
|
|
||
| @attendee_field = @form.form_fields.find_by(field_identifier: "bulk_payment_attendees") |
There was a problem hiding this comment.
it's a super nit, but i think this var should be named "attendees_field" ?
| @@ -0,0 +1,174 @@ | |||
| module Events | |||
| class BulkPaymentSubmissionsController < ApplicationController | |||
There was a problem hiding this comment.
LOVE moving these parts to their own controller!
I think we should go w what you've done. Some yagni thoughts just to have in the back of our minds...
Idk if the most important part here is BulkPayment submissions. Could just be called BulkForm submissions since you left bulk payment logic in bulk payment controller? Maybe one person needs to be able to register many people to a free event in the future, and this could be used for that?
There was a problem hiding this comment.
Ah, what about BulkPaymentFormSubmissions. Thats the actual name of the form submission and what we are working with.
I could see it potential dropping the "payment" part of the name if there are other bulk forms but some of the logic is pretty coupled to the payment part because of "pay now" and creating the stripe checkout. Good stuff to think about.
There was a problem hiding this comment.
i think BulkPaymentFormSubmissions is better than BulkPaymentSubmissions. even tho once there are 3 words i don't love 4, i think it's clearer to keep FormSubmission in there bc now its job is to focus on the form submission part.
There was a problem hiding this comment.
but i'm also ok w BulkPaymentSubmissions. a change to BulkPaymentFormSubmissions would also be better for the robots, imo.
maebeale
left a comment
maebeale
left a comment
There was a problem hiding this comment.
awesome job decluttering both event and bulk payment controllers! all for separation of concerns.
|
@jmilljr24 another thing i like about this that idk if you do is that it moves us closer to being able to have the actual payment be able to happen after submission, same as we do for event registrations. and then an irl "payment intent" would match the stripe world. as i understand it, registrants (and their bulk payer) need invoices to be able to get approval for a payment before they pay. and having the registrant names if available on the invoice is prob better for that internal process too. |
I agree on the payment intent. Not a 1-1 with stripe but same idea without a lot of complexity. |
PR #2018 splits the bulk payment flow into a public, slug-based Events::BulkPaymentSubmissions controller and an admin-only Events::BulkPayments controller, relocates the payer-facing views under bulk_payment_submissions/, replaces Events::BulkPaymentPolicy with a slug-aware FormSubmissionPolicy, and standardizes the form-responses link on the :slug param. The attendee-editing feature was built against the old single-controller layout, so move it onto that new structure rather than reintroducing the pre-refactor shape: - edit/update and the admin-only per-attendee payment status now live on BulkPaymentSubmissions (the slug-based, unauthenticated controller), authorized through FormSubmissionPolicy#edit?/#update?. - the edit view and its attendee-fields partial move alongside ticket in bulk_payment_submissions/; the ticket keeps the redesigned attendee section and points "View your form responses" at ?slug=. - the "Edit attendees" affordance re-lands on #2018's redesigned card. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2 participants
Closes [link an issue or remove this line]
What is the goal of this PR and why is this important?
Bulk payment form submission captures attendee names, however the names may need to change or may be discussed to admin via other channels. This PR separates submitted names from which registrants should be managed by this bulk payment.
How did you approach the change?
Store the linked registrant ID's in the form submission metadata. This cannot be stored on the payment because a bulk payment intent can live before the payment is made. We need to manage the linked registrants before and after payment.
The PR also refactors the bulk payment submission and bulk payment controller. The event controller was becoming a dumping ground. This has a clearer separation. The CRUD for the submission goes through
BulkPaymentSubmissionsControllerand changes/updates to the bulk payment regarding payments and allocations is handled inBulkPaymentsController.These flows are tightly coupled with events so the controllers are namespaced under events. If/when we add support for bulk payments outside of events, consideration will be made if they should move or create new ones.
Policies were updated to align with the general guidance provided by action_policy where the policy is related to the model we are acting on.
These changes also allow for the future ability to edit/change submitted names. I still don't know the best direction to go on that (do we keep the original for historic?) but because the "link" in this PR is simply add/removed an event_registration id from the form submission, the names submitted have no affect of what is managed by the admin in bulk payment index.
UI Testing Checklist
Anything else to add?
screenrecording-2026-07-28_13-55-12.mp4