Additional Waiting List Tests

[dunkOnIT]

Questions:

• What behaviour do we want if a payload is received that contains a waiting list position, but the registration isn't on the waiting list yet?
  • Reject it in the checker?
  • Add it to the waiting list at the end?
  • Add it to the waiting list in the given position?

[FinnIckler]

I think those questions are part of a larger API modelling discussion

[gregorbg]

In my opinion there's only really two options here:

1. Reject the competition because of the waiting list part of the payload explicitly
2. Drop/ignore the waiting list part of the payload implicitly

[gregorbg]

If a competition is not on the waiting list -- and, crucially, if the update payload does not specify that it wants to be put on the waiting list -- then there should be no additional information about waiting list positions.

As Finn said, this then only boils down to a general decision about "complain loudly" (and thereby implicitly don't process the waiting list part) or "ignore quietly" (and thereby implicitly don't process the waiting list part).

Adding the user in any capacity or any position to the waiting list when the same update payload does not explicitly specify "please put me to status waiting_list" gets a big no-no from me.

[dunkOnIT]

I'm partial to loudly shouting "hey, this registration isn't on the waiting list", which would be 2 tests:

1. Throw an error in the registration_checker if we get a waiting list position but no competing_status: waiting_list
2. Throw an error in the waiting_list.rb model if we call add on a Registration without a waiting_list competing_status

This leads to a second question: What if we get a payload which contains a waiting_list competing_status AND a waiting_list_position? Do we

• add it to the waiting list at the given position? Or,
• reject it because adding and moving to different positions should be done in separate steps?

[gregorbg]

I'm partial to loudly shouting "hey, this registration isn't on the waiting list", which would be 2 tests:

Okay!

This leads to a second question: What if we get a payload which contains a waiting_list competing_status AND a waiting_list_position? Do we

• add it to the waiting list at the given position? Or,
• reject it because adding and moving to different positions should be done in separate steps?

Please go with add it to the waiting list at the given position. The rationale here should be that the payload itself should support this in the backend. If we have strong opinions about what users of our website are(n't) allowed to do, then we should block these actions in the frontend.

[dunkOnIT]

If we have strong opinions about what users of our website are(n't) allowed to do, then we should block these actions in the frontend.

My only concern with this is that we also at some point want this API to be accessible by third parties - so if there's an action we don't want to support, it also needs to be enforced at the API level (at least in my view)