Add a registration deduper + fix polymorphic reassignment in the deduper engine

[maebeale]

🤖 suggested review level: 5 Inspect 🔬 new feature on shared machinery plus a correctness fix to ModelDeduper that changes merge behavior for all five deduper models

Lets admins find and merge duplicate registrations — the same person signed up for one event under two different people records (often a re-typed name) — without a developer. Along the way it fixes a latent data-corruption bug in the shared merge engine.

Registration deduper

• The (registrant_id, event_id) unique index blocks one person registering for the same event twice, so a duplicate registration only happens when a real person is registered under two different Person records. This surfaces and consolidates those.
• Wired into the existing config-driven Dedupable deduper (same as people/orgs/workshops) — no new merge engine, views, policy, or Stimulus.
• EventRegistrationServices::DuplicateFinder — clusters same-event registrations whose registrants share a name (nickname/legal-variant aware), email/email_2, or FileMaker code; flags mismatched FileMaker codes as a caution.
• Two entry points (admins only): a "Dedupe" link on the global Event registrations index, and a "Dedupe registrations" bulk action on an event's registrants page that scopes the suggested duplicates to that event and returns there.
• Non-blocking preview note: merging combines the registrations only — the two people stay separate. Merging across differently-spelled registrants is intentional (that's the common cause of the duplicate).

Engine fix (affects all deduper models)

• merge_join reassigned a polymorphic has_many … as: child (allocations, comments, bookmarks) by foreign-key id alone, so it could move — and corrupt — another type's rows that happened to share the deleted record's id.
• Now every polymorphic join is scoped by its *_type column, so a merge only ever touches this model's own rows. Counts/preview/merge all go through one join_references helper.
• Regression test added (model_deduper_spec): a same-id row of a different type is left untouched.

Notes for the reviewer

• Registration's financial allocations and comments now combine onto the kept registration correctly (the reason the fix was needed).
• Scholarships and CE registrations carry onto the kept registration; a new after_merge hook re-credits any moved scholarship to the kept registrant so its recipient matches its allocation (they differ only because a duplicate is a second registrant record). Runs inside the merge transaction.
• ModelDeduper's unhandled_references safety net still blocks (and explains) any child it genuinely can't move.
• Specs: finder unit spec + an Event registrations section in dedupable_spec.rb (surfacing, preview, merge/reassign, authorization) + the engine regression test.
• Added a Features & tips entry (registration area).

🤖 Generated with Claude Code

[maebeale]

🤖 From Claude: Load-bearing behavior change for all five deduper models, not just registrations: polymorphic has_many … as: children (allocations, comments, bookmarks) were previously reassigned by FK id alone. This adds the *_type scope so a merge can only touch this model's own rows — worth a close look since it changes existing people/org/workshop merges too.

[maebeale]

🤖 From Claude: What happens to associated records on a registration merge (D = deleted, K = kept)

Short version: nothing with money attached is lost — it all reassigns to K.

Everything moves to the kept registration

• Scholarships — linked through their allocation (Scholarship has_one :allocation, as: :source; the allocation's allocatable is the registration). The merge repoints that allocation to K, so the scholarship record is untouched and now funds K. No scholarship is destroyed.
• CE registrations — continuing_education_registrations.event_registration_id has no unique index, so every CE reg on D moves to K wholesale. Their own allocations (payments) and comments hang off the CE reg, so they ride along. Even if K and D each have a CE reg for the same license, both survive on K — nothing is cascade-deleted.
• Payments — payments are the source of allocations, never the allocatable. The merge only moves the allocatable side, so payment records are untouched.
• Attendance times, affiliations, comments — plain moves to K (no unique index on the FK to collapse anything).

Only exact duplicates collapse (no money involved)

• Checklist completions — unique [event_registration_id, step]: a step both had marked stays marked once on K.
• Organization links — unique [event_registration_id, organization_id]: a shared org link stays once on K (the org itself is fine).

One caveat — cross-registrant scholarship mismatch
Because a registration duplicate only exists when the two registrations have different registrants, a moved scholarship ends up with its recipient still pointing at D's person while its allocation now sits on K (a different person). The merge itself won't complain (it moves the allocation with update_all, skipping validations), but Scholarship#recipient_must_match_allocation_registrant would fail the next time someone edits and saves that scholarship. Merging the two people in the People deduper realigns the recipient and clears it — which is why the preview nudges you to do that too.

[maebeale]

🤖 From Claude: Open question — should the cross-registrant scholarship mismatch be fixed automatically?

When merging registrations with different registrants, I could re-point any moved scholarship's recipient to the kept registration's registrant so there's no lingering mismatch — a small addition to the merge_keeper/finder path. That would make the registration merge self-consistent on its own, without requiring the People merge as a follow-up.

Trade-off: it silently changes who a scholarship is credited to, which the People merge would otherwise do explicitly. Happy to implement it either way — flagging the decision.

[jmilljr24]

This worked really well!

Two comments, questions.

1. Is there an intended way to get to the deduper from the event management pages? I only found the link from event-reg index which isn't the primary flow for events. I wasn't sure how surfaced you wanted this feature.
2. I could be mistaken but it didn't seem like form submissions were carried over from the deleted. Could be intentional, just didn't want that to slip through if the intent was to keep them.

[maebeale]

1. adding, ty!
2. i've got a followup pr related to form submission handling.

[maebeale]

🤖 From Claude: Thanks Justin — both answered:

1. Getting to it from event management — good call, it was only on the global registrations index. Just pushed a "Dedupe registrations" entry to the Bulk actions menu on an event's registrants page. From there it's scoped to that one event (the suggested-duplicate groups only show that event's registrations) and the eyebrow returns to the event's registrants list. The global index link stays for the cross-event view.

2. Form submissions — intentional, and nothing is lost. A FormSubmission belongs to the person + event + form; it has no event_registration_id, so it was never owned by the registration row being deleted. It stays on the registrant and consolidates when you merge the two people in the People deduper (the same follow-up the preview nudges you toward for scholarships). The one loose end is the soft link some submissions keep in metadata.linked_registration_ids (a JSON array, not an FK) — that can dangle at the deleted registration's id after a merge. Happy to have the merge rewrite those to the kept registration if you'd like it tidied up; flagging rather than silently expanding scope.

[maebeale]

@jmilljr24 just an update -- i'm not going to submit the 2nd pr bc i don't think it's needed.

Submissions are not tied to Registrations, they are just tied to the Person, so a Submission is only shown on the Registrants table if its parent Person is the Registration's parent Person.

If someone dedupes registrations that have two different parent people, then the new single reg will still only show one submission. Deduping those two people will then move the form into that reg's row for visibility.

[jmilljr24]

@jmilljr24 just an update -- i'm not going to submit the 2nd pr bc i don't think it's needed.

Submissions are not tied to Registrations, they are just tied to the Person, so a Submission is only shown on the Registrants table if its parent Person is the Registration's parent Person.

If someone dedupes registrations that have two different parent people, then the new single reg will still only show one submission. Deduping those two people will then move the form into that reg's row for visibility.

Sounds good. Thanks for checking on it.