Trace registration record changes back to their form submission - #2301
Draft
maebeale wants to merge 2 commits into
Draft
Trace registration record changes back to their form submission#2301maebeale wants to merge 2 commits into
maebeale wants to merge 2 commits into
Conversation
Stamp the form submission id onto the request's buffered Ahoy lifecycle events at flush, so the records a public registration touches (person, org, tags, affiliation) can each be attributed to the submission that caused them — the basis for an upcoming per-submission "what changed" page. The id isn't knowable when events are buffered mid-request (the submission is created partway through the service), so it's stamped at flush, from a Current attribute the controller sets once the registration succeeds. Also fix SectorableItem#title: it called windows_type (a WorkshopLog-only association) for person/org sector tags, and the raise was swallowed by the lifecycle-tracking rescue — so sector tag changes were silently never logged. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
When an admin links (or creates-and-links) an org that wasn't a clean match, attribute the resulting org profile fill to the submission that named it, so that submission's "what changed" audit and count reflect the linking — the same stamping the public registration flow already does. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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
1 participant
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.
🤖 suggested review level: 3 Read 📖 contained tracking change plus one swallowed-error bug fix, backend-only, well covered by specs
Why
Foundation for an upcoming admin "what this form submission changed" page: to show everything a public registration wrote, each record's change needs to be attributable to the submission that caused it.
What
form_submission_idon lifecycle Ahoy events. NewCurrent.form_submission_id;LifecycleBuffer.flushstamps it onto each buffered event's properties. Stamped at flush because the submission is created partway through the service — after many events are already buffered. The registration controller sets it once the registration succeeds.SectorableItem#titlecalledwindows_type(aWorkshopLog-only association) for person/org sector tags; the raise was swallowed by the tracking rescue, so sector tag changes were never logged. Age groups were unaffected.#titlehad no other callers.Tests
lifecycle_buffer_spec— stamps / doesn't clobber / no-ops when unset.sectorable_item_spec—#titleno longer raises for a person; a sector tag now buffers acreate.sectorable_itemevent.public_registrations_spec— one comprehensive registration asserts every record it writes (person, address, contact_method, organization, affiliation, sectorable_item, categorizable_item, event_registration, form_submission) fires a lifecycle event carrying the submission id.