ephios-dev / ephios

ephios is a django web application for managing participation for services at events, like paramedics at a festival, lifeguards at the beach, referees and judges at competitions, etc.
https://ephios.de
MIT License
26 stars 8 forks source link

Restrict team choice if team reached maximum number of participants #1381

Closed lukasrad02 closed 1 month ago

lukasrad02 commented 1 month ago

Is your feature request related to a problem? Please describe.

At our Ephios instance, we have a shift with Direct Confirmation as signup mode and Named Teams as structure. The shift has two teams A and B that both have a maximum size set. Additionally, we have enabled Participants must provide a preferred team.

Participants are still able to select team A after it has reached its maximum size and due to Direct Confirmation, will be automatically dispatched into that team.

Describe the solution you'd like

Participants should not be able to select fully occupied teams.

Describe alternatives you've considered

Whether participants can still select fully occupied teams could be configurable per shift, instead of globally altering the default behavior.

Additional context

none

felixrindt commented 1 month ago

With how I think about it this is related to #1382.

Choosing a preferred team doesn't mean you will be assigned to it. Especially when having different qualification requirements for teams that might actually happen. I understand that you use it so people can partner up with someone they prefer, right? Did you have issues with people selecting the wrong preferred team? I would understand if instead of only suggesting a disposition for the preferred team we actually (optionally?) "set it in stone" on signup.

lukasrad02 commented 1 month ago

I understand that you use it so people can partner up with someone they prefer, right?

This was the case at our last event. This time, we used named times to distinguish different subtasks (main team and supporters).

Did you have issues with people selecting the wrong preferred team?

Previously, we did not have the problem, as people knew that each team should consist of two people ("choose your preferred partner" as you stated) and we still were on v0.16.x, hence Named Teams implied Request and Confirm, so we had to manually approve all sign-ups anyways.

However, at our current event we've experienced overoccupation of a team (as most people prefer the main team over the support team). This may be related to #1382, as those people maybe did not noticed that the main team is full. But especially since the page where one can select the team does not show any occupation information, I wouldn't consider the broken indicator the main/only reason for the overcrowded team.

I would understand if instead of only suggesting a disposition for the preferred team we actually (optionally?) "set it in stone" on signup.

Yes, such an option would be ideal for our use case. (I think manual changes should still be possible, but the signup should not be considered pending approval or similar.)

jeriox commented 1 month ago

suggesting a disposition for the preferred team

well as they use direct confirmation, the signup method is kind of designed to have no explicit disposition step, thats why most people choose it in the first place. So IMO a "fixed disposition" should be the default for direct confirmation in combination with teams