rubyforgood / rubyforgood/awbw
Block CE/scholarship creation directly on a transferred-in registration
Nobody has claimed this yet.
- Dominant language
- Ruby
- Stars
- 15
- Forks
- 26
- Avg merge
- 12h 42m
- Merged PRs (30d)
- 242
Description
Follow-up from #1944 / PR #2044.
A transferred-in registration's scholarship/CE/payments are meant to live on its source registration. The edit form hides the "Add scholarship" / "Add CE registration" cards for a transferred-in reg, but nothing stops an admin from reaching those new forms by URL and creating a scholarship or CE record against the transferred-in reg directly.
If that happens, the record sits on the wrong registration. Dashboard/revenue already exclude transferred-in regs from financial totals (billable basis), so it wouldn't inflate the new event's money — but it's still misfiled and would show nowhere useful.
Suggested fix
- Guard scholarship/CE creation (and allocation) when the target
allocatableis a transferred-in EventRegistration — reject with a clear message pointing to the source reg, or redirect there. - Consider the same guard for the bulk-payment allocation path (already excluded from the list, but the POST could still target one by id).
Context
app/models/event_registration.rb—transferred_in?.ScholarshipsController#new/create,ContinuingEducationRegistrationsController#new/create,Events::BulkPaymentsControllerallocate path.- Edit form already branches on
transferred_in?to hide the cards (_form.html.erb/_transferred_in_financials.html.erb).
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 app/models/event_registration.rb and its transferred_in? method, then trace ScholarshipsController#new/create, ContinuingEducationRegistrationsController#new/create, and the Events::BulkPaymentsController allocation path. Compare these entry points with the existing edit-form branches in _form.html.erb and _transferred_in_financials.html.erb. Done means every creation or allocation attempt targeting a transferred-in registration is blocked or redirected with a clear message pointing to the source registration.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- ruby
- Domain
- backend
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 68/100