Optionally enforce maximum number of guests per competitor on registrations

[JonEsparaz]

Allows organizers to optionally enforce a per-competitor guest limit on registrations. As mentioned in #7059 this is useful for areas still taking precautions against COVID-19 (or if they return to other areas). Outside of pandemic times, this will still be useful for competitions with limited venue space and/or championships that need to limit traffic from non-competitors.

Changes (the outermost bullets roughly align with the changes by commit):

• Add three columns: guests_per_registration_limit_enabled, guests_per_registration_limit, guests_per_registration_limit_reason, which mirror the competitor_limit* columns. I intentionally made guests_per_registration_limit_enabled separate from guests_enabled since you can ask about guests without enforcing a guest limit and I felt that determining if the guest limit is "enabled" via a null-check on guests_per_registration_limit would be confusing for users and make the code more difficult to understand.
• Make the following validations on the guest limit:
  • If you are enforcing a guest limit, you must also ask about guests.
  • The guest limit must be an integer.
  • The guest limit must be >= 1 and <= 100 (I picked 100 somewhat arbitrarily, but I doubt any cubers have that many friends).
  • A reason for the guest limit must be provided to the WCAT.
• Add a guests_per_registration_limit_enabled checkbox, guests_per_registration_limit input and guests_per_registration_limit_reason input to the competition form.
• Add Competitors may bring at most N guest text to registration requirements and validate registrations, blocking anything that exceeds an enabled guest limit.
• Add guest limit info in the WCAT email.
• Tests, plus fix handle when competition can be nil within Registration.

Closes #7059.

[gregorbg]

Thanks for your Pull Request! It's great to see that you're making more complex contributions now :)

However, in this specific case I'm not too wild about adding yet another three fields to the competitions table as if it wasn't already crammed 🙈 Do you have a basic idea on how widely used this feature would be? Covid will be over eventually...

Also, this seems related to https://github.com/thewca/worldcubeassociation.org/pull/6377. For example, it wouldn't make sense to set the Free Guest status to "Anyone can attend" but then limit the number of guests per competitor.

I hope you don't feel overwhelmed by this, but could you consider re-working your ideas and the code from that other PR by combining them into a sort of a "guest management" feature? Essentially, change the current "guest policy if entry is free" logic to be independent of the cost, and always pick a policy. Then optionally also specify a limit if the "only guests of competitors can attend" policy is picked. (That would also alleviate my concern about adding more fields to the DB, because you could probably combine and reuse a few of the existing fields)

[JonEsparaz]

Thanks for the suggestions @gregorbg!

Do you have a basic idea on how widely used this feature would be? Covid will be over eventually...

I think it would be used more than a feature like qualification requirements (although, admittedly less useful).

Long-term (when the pandemic is over), this will still be useful for areas with a high demand for competitions like Ontario (my area) and probably others like California. There's pressure to increase competitor limits to meet demand. For example, when we previously would've had 100 competitors in a room with a 250 person capacity (physical capacity, not pandemic-induced limited capacity), we'll push it to 125, but that requires having at most one guest per competitor (125 * 2 = 250).

I hope you don't feel overwhelmed by this, but could you consider re-working your ideas and the code from that other PR by combining them into a sort of a "guest management" feature? Essentially, change the current "guest policy if entry is free" logic to be independent of the cost, and always pick a policy. Then optionally also specify a limit if the "only guests of competitors can attend" policy is picked. (That would also alleviate my concern about adding more fields to the DB, because you could probably combine and reuse a few of the existing fields)

Definitely, can do! I won't get to this until the weekend, so I'll run the implementation by you first:

• Add 3: limited to the free_guest_entry_status enum, which corresponds to "Each competitor can bring a maximum of N guests"
• Just add two fields: guests_per_registration_limit and guests_per_registration_limit_reason (we don't need to add the boolean field)
  • If the WCAT doesn't need written explanation, we can drop guests_per_registration_limit_reason too

[gregorbg]

For example, when we previously would've had 100 competitors in a room with a 250 person capacity (physical capacity, not pandemic-induced limited capacity), we'll push it to 125, but that requires having at most one guest per competitor (125 * 2 = 250).

That makes a lot of sense, I have a better idea now of how useful this feature will be. Thanks!

I'll run the implementation by you first

The direction you're heading is great. A few more thoughts to refine your ideas:

• Rename the existing columns and attributes (NB a migration will be required to rename the columns!) to drop the free_ part. In theory, it should be possible to charge a guest entry fee and specify that either "Anyone can attend" or "Only attend as companions of competitors".
• Is a separate option like 3: limited really necessary? Wouldn't it suffice to alter the competition form such that if 2: restricted is picked, you can also optionally choose a limit per competitor? See assets/javascripts/competitions.js to figure out how you can conditionally make inputs appear/disappear based on form states.
• Could you reach out to WCAT via mail (with WST in CC) and clarify whether they would need a written explanation?

[gregorbg]

Also, CC @notrichardpeng since you worked on the previous feature. If you have ideas about the suggested implementation in this thread, feel free to bring them up 😄

[JonEsparaz]

Thanks @gregorbg! I just reached out to the WCAT. I'll look to get your feedback implemented in the next couple days.

[JonEsparaz]

I haven't forgotten about this, but I'm back to university this week... Once I hear back from the WCAT on their functional requirements, I'll find a couple hours to wrap this up.

(Also, I can see there's more pressing PRs and changes coming to the registration system, so no worries if this falls lower on the priority queue.)

[gregorbg]

Hey @JonEsparaz! What's the progress on this issue? There are a couple of merge conflicts to be resolved at this point, but I think we can proceed based on what WCAT has answered so far.

[JonEsparaz]

Sorry, @gregorbg. Been busy with school and other cubing responsibilities. Next opportunity I'll have to wrap this up is week of November 7.

[gregorbg]

Okay, thanks for letting me know. And good luck with whatever is keeping you busy! :smile:

[JonEsparaz]

@gregorbg should be good to go! Thanks for your patience with this PR. Please let me know if you have any feedback.

[JonEsparaz]

Comments addressed and rebase complete. Thanks for the review, @gregorbg!