Clean up historical duplicate invitation rows (one member, two invitations per event/workshop)
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
Research direction
Start by reviewing InvitationManager and PR #2867 to understand the historical lookup behavior, then trace waiting_lists.invitation_id and the associated feedback, invitation logs, and email delivery records. Before implementation, resolve the surviving role, conflicting RSVP state, and events-versus-workshops scope; done means duplicates are consolidated without losing required state or associations.
Written by the indexing model from the issue text.
Description
Summary
Before PR #2867, InvitationManager keyed invitation lookup on (event/workshop, member, role). Members subscribed as both student and coach accumulated two invitation rows per event or workshop — 387 members on the reported event (#2861). PR #2867 stops new duplicates but leaves existing rows untouched; no data migration was included.
Proposal
A data migration (or one-off rake task) that, per member per event/workshop:
- Keeps one invitation row
- Moves the attending/RSVP state from the discarded row if the member accepted on either (needs an explicit product decision if both rows have conflicting states)
- Preserves or merges associated records: waiting list entries (
waiting_lists.invitation_id, unique per invitation), feedback, invitation logs, email delivery history
Open questions
- Which row survives: Coach or Student? (The dual-role email choice issue applies to historical data too.)
- Do the duplicates carry any state we must merge rather than drop?
- Scope: events only, or workshops too?
A schema-level unique index without role (see companion issue) can only land after this cleanup.
- Dominant language
- Ruby
- Stars
- 104
- Forks
- 205
- Avg merge
- 1d 6h
- Merged PRs (30d)
- 65
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.
More from codebar/planner
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
-
good first issue performance
Difficulty 3/5 1-2 days Newbie friendliness 78/100
-
performance
Difficulty 4/5 3-5 days Newbie friendliness 58/100
Similar issues
-
user-reported
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
Kong/developer.konghq.com#7316 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
TheOdinProject/curriculum#31408 ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
notch8/utk_knapsack#148 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 78/100
Homebrew/homebrew-cask#288729 · 1 comment ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100