HOLD UNTIL REQUESTED: Let admins register attendees without sending them a confirmation email#1626
Open
maebeale wants to merge 4 commits into
Open
HOLD UNTIL REQUESTED: Let admins register attendees without sending them a confirmation email#1626maebeale wants to merge 4 commits into
maebeale wants to merge 4 commits into
Conversation
maebeale
commented
Jun 11, 2026
|
|
||
| # An admin (or event owner) registering someone else: only honored for users | ||
| # who can manage the event, so a guest can't suppress their own confirmation. | ||
| def on_behalf? |
Collaborator
Author
There was a problem hiding this comment.
🤖 From Claude: Gated on allowed_to?(:dashboard?, @event) so a logged-out visitor can never set on_behalf to suppress their own confirmation — the flag is ignored unless the requester can manage the event.
maebeale
commented
Jun 11, 2026
| # logged-out form so they can register a not-logged-in person; the fields | ||
| # that are normally hidden for the logged-in admin are flagged as | ||
| # "behalf-only" and revealed client-side when "on behalf" is checked. | ||
| def set_field_variables |
Collaborator
Author
There was a problem hiding this comment.
🤖 From Claude: Admins always get the full logged-out field set because the person being registered isn't logged in. The diff against the logged-in set (@behalf_only_field_ids) is what the Stimulus controller reveals/hides as the toggle changes.
791e990 to
048bf8f
Compare
Collaborator
Author
|
@jmilljr24 this offers an alternative to |
4 tasks
4a9821c to
fab69c0
Compare
Staff often register people on their behalf, where a "thanks for registering" email to the attendee is unwanted noise. Adds an admin-only "on behalf" mode to the public registration form that suppresses the registrant confirmation while still sending the staff FYI, and reveals the identity fields the form normally hides for a logged-in user (the attendee isn't logged in, so those fields must be filled in). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The param was never read by Events::PublicRegistrationsController, so it had no effect on the rendered form — removing the noise.
Admins should see the on-behalf option before reading the form instructions, so move it to the top of the form (above forms/header).
fab69c0 to
4be561a
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes [link an issue or remove this line]
What is the goal of this PR and why is this important?
How did you approach the change?
PublicRegistrationgained asend_confirmation:flag; the controller only honorson_behalffor users who can manage the event, finds/creates the registrant from the form (not the admin), and keeps the admin FYI.on-behalfStimulus controller, with "Register on behalf" entry points on the registrants roster and the event Form actions menu.UI Testing Checklist
Anything else to add?