Yiran li/feature/create shift api v2

[yiranlir]

Describe your changes

In this PR, we mainly implemented the functionality for creating new shift requests. I also enhanced the update_status function by introducing a conflict check when the status is changed to accepted, ensuring that any conflicting shifts are detected before the status is updated. Additionally, an unavailability time record is created when a shift is accepted. Furthermore, we made modifications to the database schema by adding the shift_position table and establishing relationships between the shift_request, shift_request_volunteer, and shift_position tables.

Functional changes

Create new shift

We added functionality to allow users to create new shift requests. These requests include details such as title, start time, end time, and vehicle type. Based on the vehicle type, the system determines the number and types of volunteer roles (such as 'Crew Leader', 'Driver', 'Advanced', and 'Basic') required for the shift. These roles are then stored in the shift_position table, ensuring that each shift has the correct set of roles assigned to it.

Update Status

The update_status function was enhanced to incorporate conflict detection when a shift status is changed to accepted. When the status is updated to accepted, the system performs a conflict check by querying the database for any other confirmed shifts assigned to the same volunteer that overlap in time. If a conflict is detected, the status change is rejected, and a ConflictError is raised. If no conflict is found, the status is updated, and an unavailability_time record is created, marking the volunteer's time as unavailable during the shift period. This ensures accurate scheduling and prevents volunteers from being double-booked.
Additionally, the function handles updating shifts to other statuses, such as rejected. When a shift is rejected, the status is simply updated without further checks.

Database Changes

Add shift_position table

The shift_position table was introduced to store information about the roles required for each shift based on the type of vehicle involved. The create_positions function dynamically generates positions for each shift according to the vehicle_type. Depending on the vehicle type, a predefined set of roles (e.g., crewLeader, driver, advanced, basic) is assigned to the shift. For example:
Heavy Tanker: Six roles are assigned—crewLeader, driver, two advanced, and two basic roles.
Medium Tanker: Four roles are assigned—crewLeader, driver, advanced, and basic.
Light Unit: Two roles are assigned—driver and basic.
Each role is saved as a record in the shift_position table, with the associated shift_id and role_code. This flexible design allows different vehicle types to require varying numbers and types of volunteers for each shift.

Modify unavailability_time table

The unavailability_time table was updated with a new column called is_shift. This column is a boolean field that indicates whether the unavailability time corresponds to a scheduled shift. When a volunteer accepts a shift, a corresponding unavailability time record is created with the is_shift flag set to True. This allows the system to distinguish between general unavailability times and those specifically associated with accepted shifts.

Status Enum Updates

The status enums were updated for both ShiftStatus and ShiftVolunteerStatus to reflect clearer stages in the shift lifecycle. For ShiftRequest, statuses such as "pending," "submitted," "confirmed," and "completed" were introduced. For ShiftRequestVolunteer, "accepted" replaced the former "confirmed" status to better align with the system's workflow.

I have already done some basic test for these updates in Postman.

Issue ticket number and link

https://fireapp-emergiq-2024.atlassian.net/browse/FIR-112?atlOrigin=eyJpIjoiNmMyYmJiODlhZWI5NGUwY2JjYmIwNzkwMGY5N2M3ZTMiLCJwIjoiaiJ9

[5oappy]

merging of my branch could have been omitted, but its good to know that there is no explicit errors with both branches being merged at least. now we can just focus on the functional correctness.

[emilymclean]

Will review once the merged branches are in main so I can see your changes better

[5oappy]

Good stuff Linda, your changes have already been merged into a separate branch and begun testing already and seems functional.

I approve of this merge.

@BenMMcLean any further modifications to code will now be headed by 5oappy/feature/integration-testing-schedulerv2 which is the backend branch I am using to run the front end and test dynamically.

[emilymclean]

I'm quite happy with this code, my only requested change would be to add type hints to the repository functions. Happy to leave those minor changes to the other branch @5oappy.