Skip to content

Shifts ‐ Overview

Jump to bottom
Théophile MADET edited this page Jul 16, 2024 · 4 revisions

Vocabulary

ABCD vs Non-ABCD shifts

As explained in our vocabulary section, ABCD shifts are represented by the ShiftTemplate model, while Non-ABCD shifts are represented by the Shift model. When we say just "shift", we usually mean "non-abcd shift". We'll use that convention for the rest of this page.

Shift instance

Some shifts happen only once and are created manually, for example inventory shifts or specific responsibilities during an event. However, most shifts are an instance of an ABCD shift. For example, Supermarkt Tue, 09 Jul 2024 08:15 - 11:15 (B) is an instance of Supermarkt Dienstag 08:15 (B).

Each instance has its own database object (a Shift). They are created automatically using the tapir.shifts.utils.generate_shifts_up_to function, which is called automatically every day at midnight by celery with the generate_shifts task, defined in settings.py.

Registration

Often, we colloquially say "register to a shift", which is wrong: a member registers to a slot within a shift, not to a shift.

Attendance states

The possible states of an attendance are defined in ShiftAttendance.State:

  • PENDING is the default state when the attendance is created. It means we don't know yet if the member has showed up to their shift, but they are expected to.
  • DONE means that the attendance sheet was signed, the member as showed up.
  • CANCELLED means that the attendance is, well, cancelled. The member is not expected to show up. This can mean for example that the shift got cancelled (for example if it lands on a holiday), or that a flying member de-registered.
  • MISSED means that the member didn't show up and was not excused.
  • MISSED_EXCUSED means that the member is excused: they are not expected to show up but still get the attendance point. Typically, it means that they were sick on the day of the shift.
  • LOOKING_FOR_STAND_IN means that the member is looking for someone to replace them. They cannot unregister (for example because this is their ABCD shift) but can't show up, so they are looking for someone to replace them. A few constant lists are defined to make groups of attendance types more clear, like STATES_WHERE_THE_MEMBER_IS_EXPECTED_TO_SHOW_UP.

The registration/attendance process

Shift

Registration

  1. The member visits the shift calendar: ShiftCalendarView
  2. They pick a shift and land on the shift's detail page: ShiftDetailView
  3. They pick a slot and click the register button to land on the registration page: RegisterUserToShiftSlotView.
  4. If they confirm the registration, the first actual action is performed: a ShiftAttendance is created with the pending state

Attendance

The next steps can vary depending on if the member shows up, if they get sick, look for a replacement... Here the steps for the standard case: the member does who up to the shift.

  1. The member signs the attendance sheet (printed with ShiftDayPrintableView).
  2. The member office goes through the attendance sheet, checking who showed up.
  3. The member office goes to the shift detail page. That page has several buttons that link to the UpdateShiftAttendanceStateView, which directly updates the state.
  4. The attendance is updated and the user's score is updated accordingly, if relevant. This is done in ShiftAttendance.update_shift_account_entry.

ABCD shifts

Members can't register themselves to ABCD shifts, instead they must ask the member office to do it. The process is similar to non-abcd shift: go the the ABCD-shift calendar, selects the desired shift and slot, then register the member. The difference is in what happens when the registration is confirmed: in RegisterUserToShiftSlotTemplateView, a ShiftAttendanceTemplate is created, but also one ShiftAttendance is created for every future instance of that ABCD shift.

If more shift instances are created, the corresponding shift attendances must be created too. This happens through ShiftSlot.update_attendance_from_template.

The shift score

Each member has a shift score that they must keep at 0 or above. The current score is the sum of all their ShiftAccountEntry.value. Score entries get created and updated in SHiftAttendance.update_shift_account_entry

Every (active, non-exempted) member automatically gets one negative point added to their score at the beginning of their shift cycle. This is done in ShiftCycleService.apply_cycle_start, called automatically with the apply_shift_cycle_start celery task.

Since members start with a score of 0 and get -1 at the beginning of their first cycle, it means that a score of -1 is actually normal, they just haven't done their shift of the cycle yet. Only scores from -2 downward are a sign of a problem.

Clone this wiki locally