codebar / codebar/planner

Which invitation a dual-role member receives is decided by pass order, not product intent

Open
#2,902 1 comment 0 reactions 0 assignees View on GitHub

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?

  1. Keep pass order (current behavior: Coach for events, Student for workshops)
  2. Coach email always wins
  3. 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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.