search

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

Named team is not shown as fully occupied when signup mode ist set to Direct Confirmation #1382

Closed lukasrad02 closed 1 month ago

lukasrad02 commented 1 month ago

Describe the bug

A named team that has reached its maximum number of participants is still shown as "needs participants" if the signup mode is set to Direct Confirmation.

To Reproduce

Steps to reproduce the behavior:

  1. Create an event
  2. Create two shifts on that event. Both shifts should have the structure Named Teams with a team A with a maximum size of 1. The first shift should use the signup mode Direct Confirmation, the other one should be set to Request and Confirm
  3. Sign up for both shifts and select team A during signup. Confirm signup for the shift that requires confirmation.
  4. Check the checkmark icon on the right: The Direct Confirmation shift shows that participants are still needed, while the Request and Confirm shift shows to be full. (See screenshot below)

Expected behavior

The indicator icon should always show the correct state. In the example from above, it should show "fully occupied" for both teams.

Screenshots

The shift on the left side uses Direct Confirmation (notice the "Participate" button), while the one on the right side uses Request and Confirm. The checkmark icon of the left shift is wrongly stating that participants are missing.

Screenshot of what is described in step 4 above

The bug also affects teams in "enough participants" state:

Similar scenario to the previos screenshot, but both teams are now configured to allow 1-2 people. The left indicator wrongly states that participants are needed, while the right one displays the correct state.

Environment

Lastest ephios version (0.17.1) as well as latest commit from main branch (0609b0e)

Additional context

The indicator shows the correct state after manual disposition. However, this requires assigning the user to another team first.

felixrindt commented 1 month ago

In part, this is intended behaviour, because given you qualify for both A and B, you could be assigned to both regardless of what you prefer, so any one team is missing a participant. I agree that this is confusing in this setup and how we render it. I'll look into potential other situations where this is the case, compare it with how complex behaves (maybe we can add auto Dispo for teams too) and implement a fix.

lukasrad02 commented 1 month ago

I've just noticed that the overall number of missing participants shown in the event list is also wrong. Consider the following event from our prod instance:

Screenshot 2024-10-19 at 10-25-52 ephios - Bar

Notice: For privacy reasons, I've removed all names from the screenshots. Grey boxes (only present at the last 3 shifts) represent available slots, white boxes represent slots that are occupied by a participant. There are no participations pending disposition. For some shifts, we did some manual disposition afterwards (notice the correctly displayed checkmarks for full teams at some shifts), while at some shifts there has never been any manual disposition.

I would expect that there are 6 participants missing. However, the overview page shows 22 missing participants, which is highly misleading for both helpers searching for free shifts as well as us to estimate how many helpers are still needed:

Screenshot 2024-10-19 at 10-21-32 ephios - Veranstaltungen

Notice: Due to #1381, we have switched all shifts from Direct Confirmation to Request and Confirm. I'm not sure whether the wrong overall number might be caused by this change and haven't had the time to check this, but I would expect it to also be wrong if we did not change the shift configurations.

Edit: This behavior is also not aligned with your previous statement

given you qualify for both A and B, you could be assigned to both regardless of what you prefer, so any one team is missing a participant

as in our current case, all participants qualify for all teams (there are no qualifications required for any team), so independent from the actual assignment to the teams, there should never be more than 6 participants missing.

lukasrad02 commented 1 month ago

The indicator shows the correct state after manual disposition.

In contrast to my minimal setup in a local dev instance, I cannot make this work in our production instance (v0.17.1, Docker), so in we currently have no way to prevent people from still requesting participation for these shifts.

I don't want to require a qualification that nobody has or set the shifts to manual disposition only if they are full, as participants are allowed to withdraw their registration, which would leave us with actually not fully occupied shifts nobody can sign up for. Do you have any other suggestions how we can fix this?