Auto Accept PR 2: Frontend & Waiting List Integration

[dunkOnIT]

Frontend Changes

• [x] Give organizers a way to toggle auto-accept off
• [x] Add disable auto accept button for organizers when auto accept is enabled
• [x] Add enable/disable auto accept settings in the competition form
• [x] Make the "Disable Auto Accept" button actually do something when it is clicked, to indicate whether or not auto accept was successfully disabled

Backend Changes

• [x] Auto-accept users onto waiting list when Accepted is full
  • [x] ~Should they be accepted onto the waiting list if the auto-accept-cutff has been reached?~ No - consulted people on discord
• [x] Auto-accept users from waiting list if a spot becomes available in the accepted list (ie, if an attendee's status changes away from accepted
• [x] Add bulk auto accept class method
• [x] Add bulk auto accept route
• [ ] Test if registration history and state change emails get created/sent as expected

Future PR

• [ ] Move waiting list to above the accepted list if it has at least one registration || competitor_limit has been reached | auto_accept is enabled and auto_accept_disable_threshold has been reached
• [ ] Warn an organizer if they're trying to accept a user from the Pending list while there are registrations on the Waiting List
• [ ] Give organizers a way to toggle auto-accept on
• [ ] Give organizers a way to run a bulk auto-accept
• [ ] Automatically run bulk auto-accept when auto-accept is toggled on
  • [ ] Warn organizers this will happen, and give them an "Are you sure?" dialogue, where saying "No" will

[dunkOnIT]

Waiting list:

• Accept a user from the waiting list if a spot becomes available on the Accepted list
• [ ] Model Tests
  • [x] allow auto-accepting the first position on the waiting list
• [ ] Integration Tests
  • [ ] Trigger an auto_accept job from the competing lane if a user's status changes away from accepted

[dunkOnIT]

Add to waiting list:

• If the Accepted list is full, accept users onto the Waiting List
  • What if the auto_accept_disable threshold is reached?

[dunkOnIT]

Bulk auto accept class method tests:

• [ ] Accepts competitors from the waiting list
  • [ ] in order of waiting list
• [ ] Accepts pending competitors
  • [ ] in order of payment
• [ ] Accepts up to but not exceeding the competition limit
  • [ ] those not accepted follow the expected order (later on waiting list = not accepted, later payment = not accepted)

[dunkOnIT]

Ok I'm now combining a useQuery and prop strategy by setting competitionInfo as a state. Just useQuery was causing a lot of issues with competitionInfo not being loaded initially, and it seemed better to just hydrate it rather than add a bunch of conditionals on everything trying to access competitionInfo.

Current issues:

• [ ] "Disable Auto Accept" button not disappearing when competitionInfo reloads - the change in state is not being picked up by autoAcceptEnabled
• [ ] Getting inconsistent results with disableAutoAcceptMutation - it often triggers the onError block even though the API call is succeeding - so perhaps it isn't awaiting the result of disableAutoAccept? I'm not quite sure what's happening there.

In any case, we're close - should finish it off by tomorrow morning. Open to input on whether there's a better way to handle competitionInfo with the dual hydration/fetch strategy

[FinnIckler]

the issue with it not being hydrated at first is because you are not waiting for competitionInfo to be loaded before rendering. You could just fetch it in a parent component (and have a return <Loading /> while it loads), or use competitionInfo?. access everywhere in the component where you are fetching it

[dunkOnIT]

@kr-matthews would you be able to help resolve the merge conflict in RegistrationAdministrationList? Particularly in line ~580 - it seems like how we render the lists may have changed?

[kr-matthews]

@kr-matthews would you be able to help resolve the merge conflict in RegistrationAdministrationList? Particularly in line ~580 - it seems like how we render the lists may have changed?

Will take a look tomorrow. The headings/lists have just been moved from the return to an array, the contents should all be the same.

[kr-matthews]

@kr-matthews would you be able to help resolve the merge conflict in RegistrationAdministrationList? Particularly in line ~580 - it seems like how we render the lists may have changed?

The import conflict is easy to fix: accordion, button, and icon should all be new imports. For the other one, I think git might only be confused because you added a few new lines within the return, but the surrounding lines were moved in my work. If you remove those new lines (before trying to merge with main), the conflict will probably go away?

[dunkOnIT]

Thanks, conflicts resolved!