Auto Accept PR 2: Frontend & Waiting List Integration

[dunkOnIT]

Frontend Changes

• Give organizers a way to toggle auto-accept off
• Add disable auto accept button for organizers when auto accept is enabled
• Add enable/disable auto accept settings in the competition form
• 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

• Auto-accept users onto waiting list when Accepted is full
  • Should they be accepted onto the waiting list if the auto-accept-cutff has been reached? No - consulted people on discord
• 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
• Add bulk auto accept class method
• 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
  • 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 while it loads), or use competitionInfo?. access everywhere in the component where you are fetching it