Which invitation a dual-role member receives is decided by pass order, not product intent
Nobody has claimed this yet.
- Dominant language
- Ruby
- Stars
- 104
- Forks
- 205
- Avg merge
- 1d 5h
- Merged PRs (30d)
- 63
Description
Summary
PR #2867 made (event/workshop, member) the invitation identity, so a member subscribed as both student and coach now receives exactly one invitation and one email. Which email that is depends on the invitation pass order: Coach first for events, Student first for workshops. The order is an implementation detail, not a product decision.
The specs in PR #2867 pin the surviving role and email subject, so a pass reorder cannot flip this silently — but if product wants, for example, the coach email to always win, that is a separate change.
Decision needed
For a member with both roles, which invitation should win?
- Keep pass order (current behavior: Coach for events, Student for workshops)
- Coach email always wins
- Student email always wins
Related: cleanup of existing duplicate rows (see companion issue), where the same "which one survives" question applies to historical rows.
Related design call (from the PR #2867 review): verified/attending state across role flips
The role flip carries verified and attending state across roles. Admin::InvitationController sets verified: true per row, and Event#verified_students / Event#verified_coaches select by role + accepted + verified. Consequence: a verified Coach invitation flipped to Student (via the self-RSVP role-choice-wins path in find_or_create_invitation) counts in verified_students with no admin action, and the coach-side verified record is gone. Under the old two-row design, verification stayed per role.
If product picks option 1 above (pass order), this needs no action. If product picks option 2 or 3, the flip direction should also decide whether a role change resets verified (and possibly attending).
Flagged by the ce-code-review run on PR #2867 (adversarial + correctness reviewers, confirmed by validation).
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with PR #2867 and the invitation flow in find_or_create_invitation. Read Admin::InvitationController, Event#verified_students, and Event#verified_coaches to understand how role, verified, and attending state are carried across role flips. Product must first choose which invitation wins and whether role changes reset state; done means the chosen behavior is implemented and protected by the existing specs.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- ruby
- Domain
- backend
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100