Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support non-competing staff members #7491

Closed
timreyn opened this issue Dec 24, 2022 · 6 comments · Fixed by #7601
Closed

Support non-competing staff members #7491

timreyn opened this issue Dec 24, 2022 · 6 comments · Fixed by #7601
Labels
SERVICE: competition STATUS: needs discussion/design Team either needs to discuss this issue, or put that discussion into writing. TECH: database This issue requires interaction with a database TECH: ruby Requires knowledge of Ruby

Comments

@timreyn
Copy link
Contributor

timreyn commented Dec 24, 2022

Is your feature request related to a problem? Please describe.
For CubingUSANationals2023, we will have staff members who are not competing in the competition. Some staff members are qualified for zero events and thus unable to register, but we would still like to give them judging and running assignments.

I've tried inserting a fake Registration for a non-competing staff member, with zero registered events, but this fails validations.

Describe the solution you'd like
Create a fake Registration, with a new boolean field is_competitor set to false, which would disable some validations. This can just be created by the WCIF PATCH API, it probably doesn't need its own UI.

Describe alternatives you've considered
#7483 provides another option:

  • Create a competition_persons table, including all people with a role at the competition -- organizer, delegate, staff, competitor, etc
  • Change the assignments table from having a registration_id field to having a competition_person_id field
  • Expose everyone in competition_persons in the competition WCIF, joining with their Registration

This is a bigger change that's going to touch a lot of registration code and schema, and with the possibility of an upcoming registration overhaul I'm nervous about a lot of this being wasted effort. The solution I proposed above is probably much easier.

Additional context
I think this is a relatively uncommon request, and most non-championship competitions don't need to have non-competing staff members with jobs listed in WCIF. So I'm proposing just doing this via API, rather than making a new UI for it.

I'm happy to do the work on this, if my approach is okay.

Finally, I would also like to add WCIF extensions to Persons, which would be much simpler if there's a single kind of parent entity -- either Registration or CompetitionPerson, preferably not a hybrid where competing people have extensions attached to Registration, and non-competing people have extensions attached to some other object.

timreyn added a commit to timreyn/worldcubeassociation.org that referenced this issue Jan 5, 2023
@dunkOnIT dunkOnIT added TECH: ruby Requires knowledge of Ruby STATUS: needs discussion/design Team either needs to discuss this issue, or put that discussion into writing. TECH: database This issue requires interaction with a database labels Jan 16, 2023
@timreyn
Copy link
Contributor Author

timreyn commented Jan 29, 2023

Hi -- I was wondering if you had any thoughts about this. There's a proof-of-concept implementation here timreyn@75d5e20 (not totally sure how this should look in the "edit registrations" page). Would appreciate some feedback if this is a good design or not. Thank you!

@coder13
Copy link
Contributor

coder13 commented Jan 29, 2023

If I could upvote this I would.

@FinnIckler
Copy link
Member

I am all for it. Open Questions that I have when reading the poc are

  • Will these people be shown in the Registration tab?
  • If yes, how do we make sure these people are not counted for alerts like "Note: The competitor limit for this competition has already been reached. " or showing up in the competitor list.
  • Should there maybe even be a separate staff list?

@timreyn
Copy link
Contributor Author

timreyn commented Jan 29, 2023

@FinnIckler Thanks!

I believe that since the registration is not "accepted", they wouldn't show up by default in either the competitor list or the competitor limit. See also timreyn@75d5e20#diff-dbc8f8d952b72329f21999d4269b470a993f33593a5fefb6076c9bb915d9fd5e

A separate staff list could be useful, and this could be included in the /edit/registrations page as a separate list. However, given that this is probably going to be used infrequently, it might be confusing if most competitions had an empty list of non-competing staff, just so that a few can have a staff list with people on it.

@dunkOnIT
Copy link
Contributor

dunkOnIT commented Feb 3, 2023

@timreyn my counterpoint would be that the competitions which need it - I'm thinking of championships in particular - would really need it.

Personally I'd be fine with an extra field (perhaps below "deleted" registrations?), that I'd expect most organisers wouldn't be troubled with.

timreyn added a commit to timreyn/worldcubeassociation.org that referenced this issue Feb 4, 2023
@timreyn
Copy link
Contributor Author

timreyn commented Feb 4, 2023

@dunkOnIT sounds good.

Thanks all for the feedback!

timreyn added a commit to timreyn/worldcubeassociation.org that referenced this issue Feb 10, 2023
gregorbg pushed a commit that referenced this issue Feb 26, 2023
* Add support for non-competing staff.

Fixes #7491.

* Fix lint errors.

* Add missing frozen string literal comment

* Export non_competing_staff column

* Code review fixes

* Switch the semantics of is_competing to be positive

* Undo stray edits to db/structure.sql
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
SERVICE: competition STATUS: needs discussion/design Team either needs to discuss this issue, or put that discussion into writing. TECH: database This issue requires interaction with a database TECH: ruby Requires knowledge of Ruby
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

4 participants