Releases: TechlauncherFireApp/backend
Releases · TechlauncherFireApp/backend
fireapp-3.119.0-alpha.7767
Chim/feature/integrate noti optimiser (#307) ## Describe your changes 1. I add notification functionality inside `save` method in optimiser class. ## Issue ticket number and link [Jira](https://fireapp-emergiq-2024.atlassian.net/jira/software/projects/FIR/boards/2?selectedIssue=FIR-122)
fireapp-3.119.0-gh-readonly-queue-main-pr-306-7957255724693fc492d6167ad085c4292443780c.1
5oappy/feature/integration testing schedulerv2 (#306)
## Describe your changes
note: merged lindas changes into this branch before Linda's was merged
into main so there may be some inconsistencies that will need to be
manually resolved.
real changes begin at 1ecbfe08a58d8baad160e5cb47070d7895248ec4.
I know its a mess but it works!!
The scheduler works correctly according to this control flow:
1) api is called and..
2) optimiser instance is created
3) optimiser invokes calculator instance
4) calculator instance retrieves all required data
5) optimiser calls calculator methods to assign varaibles
6) minizinc instance created with the model string
7) variables are assigned to minizinc model string
8) minizinc solves the model
9) minizinc returns the posssible assignments
10) possible assignments are returned to api
11) api invokes save result to persist possible assignments to database
and setting relevant flags.
12) api returns {"message": "Optimisation completed successfully",
"result": <minizinc result string>}
Further info on calculator:
- The scheduler will optimise all recently created shifts marked via the
status flag being set to SUBMITTED (as in just submitted).
- The scheduler will allow for users to be assigned to multiple shifts
provided their skills align.
- The scheduler will allow for clashes in scheduling.
- The actual saving of volunteer shift will check for clashes.
- `unavailability_record` is created for each successful user assigned
and saved to the shift (each `shift_request_volunteer` entry added to
the db). This prevents the optimiser from thinking user is available for
subsequent optimisations.
pictures:
before calling optimiser:
<img width="871" alt="Screenshot 2024-10-06 at 11 13 05 PM"
src="https://github.com/user-attachments/assets/e492839f-f0e8-4e9b-9029-a73b304c466c">
after calling optimiser:
<img width="871" alt="Screenshot 2024-10-06 at 11 13 20 PM"
src="https://github.com/user-attachments/assets/f0711a5f-50b9-49e1-ba28-c75facb1e7e0">
logs:
<img width="821" alt="Screenshot 2024-10-06 at 11 56 37 PM"
src="https://github.com/user-attachments/assets/3d0c4c5b-3c4b-4970-b34e-301f6fafbb25">
<img width="186" alt="Screenshot 2024-10-07 at 12 00 01 AM"
src="https://github.com/user-attachments/assets/c52f2c5d-39cd-4b7f-b963-fe5741cf0dfd">
<img width="197" alt="Screenshot 2024-10-07 at 12 01 48 AM"
src="https://github.com/user-attachments/assets/ba65dc65-365e-4c8d-a658-85df00b2e4da">
<img width="193" alt="Screenshot 2024-10-06 at 10 16 14 PM"
src="https://github.com/user-attachments/assets/584080c2-5f41-4a2e-92d0-9f505084e4b7">
note: the second phone has duplicate shifts because of a bug that
allowed 2 shifts to be posted via post man at the same time and got
persisted when the optimiser was not set up to handle clashes yet.
signed:
Steven, Hafizh, Linda.
## Issue ticket number and link
[FIR-4](https://fireapp-emergiq-2024.atlassian.net/browse/FIR-4)
[FIR-108](https://fireapp-emergiq-2024.atlassian.net/browse/FIR-108)
---------
Co-authored-by: YiranLI <lyr060614@163.com>
Co-authored-by: anannnchim <nachimchim@gmail.com>
Co-authored-by: Muhammad Hafizh Hasyim <u7316882@anu.edu.au>
fireapp-3.119.0-alpha.7766
5oappy/feature/integration testing schedulerv2 (#306)
## Describe your changes
note: merged lindas changes into this branch before Linda's was merged
into main so there may be some inconsistencies that will need to be
manually resolved.
real changes begin at 1ecbfe08a58d8baad160e5cb47070d7895248ec4.
I know its a mess but it works!!
The scheduler works correctly according to this control flow:
1) api is called and..
2) optimiser instance is created
3) optimiser invokes calculator instance
4) calculator instance retrieves all required data
5) optimiser calls calculator methods to assign varaibles
6) minizinc instance created with the model string
7) variables are assigned to minizinc model string
8) minizinc solves the model
9) minizinc returns the posssible assignments
10) possible assignments are returned to api
11) api invokes save result to persist possible assignments to database
and setting relevant flags.
12) api returns {"message": "Optimisation completed successfully",
"result": <minizinc result string>}
Further info on calculator:
- The scheduler will optimise all recently created shifts marked via the
status flag being set to SUBMITTED (as in just submitted).
- The scheduler will allow for users to be assigned to multiple shifts
provided their skills align.
- The scheduler will allow for clashes in scheduling.
- The actual saving of volunteer shift will check for clashes.
- `unavailability_record` is created for each successful user assigned
and saved to the shift (each `shift_request_volunteer` entry added to
the db). This prevents the optimiser from thinking user is available for
subsequent optimisations.
pictures:
before calling optimiser:
<img width="871" alt="Screenshot 2024-10-06 at 11 13 05 PM"
src="https://github.com/user-attachments/assets/e492839f-f0e8-4e9b-9029-a73b304c466c">
after calling optimiser:
<img width="871" alt="Screenshot 2024-10-06 at 11 13 20 PM"
src="https://github.com/user-attachments/assets/f0711a5f-50b9-49e1-ba28-c75facb1e7e0">
logs:
<img width="821" alt="Screenshot 2024-10-06 at 11 56 37 PM"
src="https://github.com/user-attachments/assets/3d0c4c5b-3c4b-4970-b34e-301f6fafbb25">
<img width="186" alt="Screenshot 2024-10-07 at 12 00 01 AM"
src="https://github.com/user-attachments/assets/c52f2c5d-39cd-4b7f-b963-fe5741cf0dfd">
<img width="197" alt="Screenshot 2024-10-07 at 12 01 48 AM"
src="https://github.com/user-attachments/assets/ba65dc65-365e-4c8d-a658-85df00b2e4da">
<img width="193" alt="Screenshot 2024-10-06 at 10 16 14 PM"
src="https://github.com/user-attachments/assets/584080c2-5f41-4a2e-92d0-9f505084e4b7">
note: the second phone has duplicate shifts because of a bug that
allowed 2 shifts to be posted via post man at the same time and got
persisted when the optimiser was not set up to handle clashes yet.
signed:
Steven, Hafizh, Linda.
## Issue ticket number and link
[FIR-4](https://fireapp-emergiq-2024.atlassian.net/browse/FIR-4)
[FIR-108](https://fireapp-emergiq-2024.atlassian.net/browse/FIR-108)
---------
Co-authored-by: YiranLI <lyr060614@163.com>
Co-authored-by: anannnchim <nachimchim@gmail.com>
Co-authored-by: Muhammad Hafizh Hasyim <u7316882@anu.edu.au>
fireapp-3.119.0-gh-readonly-queue-main-pr-305-91fbcb921f2126a869344141e9799dcc295a8fae.1
Chim/feature/add notification service (#305) ## Describe your changes I've add 3 functions: 1. `send_notification` in the `NotificationService` class 2. `get_fcm_token` and `notify_user` in the `FCMTokenRepository` class Functionalities: 1. Given a list of fcm token, `send_notification` will allow other parts of the program to call for sending any message or notification. 2. Given a user id, `get_fcm_token` will retrieve all fcm tokens for a given user and return in a list of token string. 3. Gvien a userId or a list of fcm token, `send_notification` can be used to send notification to users. ## Issue ticket number and link [Jira](https://fireapp-emergiq-2024.atlassian.net/jira/software/projects/FIR/boards/2?selectedIssue=FIR-99)
fireapp-3.119.0-alpha.7765
Chim/feature/add notification service (#305) ## Describe your changes I've add 3 functions: 1. `send_notification` in the `NotificationService` class 2. `get_fcm_token` and `notify_user` in the `FCMTokenRepository` class Functionalities: 1. Given a list of fcm token, `send_notification` will allow other parts of the program to call for sending any message or notification. 2. Given a user id, `get_fcm_token` will retrieve all fcm tokens for a given user and return in a list of token string. 3. Gvien a userId or a list of fcm token, `send_notification` can be used to send notification to users. ## Issue ticket number and link [Jira](https://fireapp-emergiq-2024.atlassian.net/jira/software/projects/FIR/boards/2?selectedIssue=FIR-99)
fireapp-3.119.0-gh-readonly-queue-main-pr-301-58313c3020191a8e343e952179c5d6b989e8a32c.1
Yiran li/feature/create shift api v2 (#301) ## 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 --------- Co-authored-by: anannnchim <nachimchim@gmail.com> Co-authored-by: Steven (Quoc) <u7108792@anu.edu.au>
fireapp-3.119.0-alpha.7764
Yiran li/feature/create shift api v2 (#301) ## 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 --------- Co-authored-by: anannnchim <nachimchim@gmail.com> Co-authored-by: Steven (Quoc) <u7108792@anu.edu.au>
fireapp-3.119.0-gh-readonly-queue-main-pr-300-e91734abe3309ab29bf330ca41a504e46f48d8c4.1
Fishchimp/feature/optimiser v2 2 (#300) ## Describe your changes Refactor and Enhancement of the Optimiser Class for Shift and Volunteer Assignment This PR focuses on improving the Optimiser class's overall code readability, functionality, and alignment with the new requirements for volunteer shift management. Major changes include the replacement of vehicle-based requirements with role-based requirements, the addition of logging for better debugging, and the introduction of new constraints for skill and compatibility handling in the optimisation model. **Key Changes:** 1. **Logging Integration:** - Added logging functionality to track errors and provide insights during the optimisation process. - Enhanced the debugging output for clearer visibility of the optimiser's internal state. 2. **Role-Based Optimisation:** - Transitioned from the asset/vehicle-based logic in the old implementation to a role-based structure in the new version. - Replaced `AssetRequestVolunteer` and `AssetRequestVehicle` logic with `ShiftRequestVolunteer` to align with shift management requirements. 3. **MiniZinc Model Refactor:** - Introduced a new MiniZinc model that simplifies the assignment of volunteers to shifts and roles. - The compatibility, mastery, and skill requirements are now handled with flattened 1D matrices to optimise the data passing to the solver. - Constraints added to ensure that volunteers are only assigned to roles they are compatible with and have mastered. 4. **Constraints and Objective:** - The new model includes constraints for skill requirements, ensuring the required number of roles is filled. - The objective is now focused on maximising the number of valid role assignments while respecting constraints. 5. **Improved Database Handling:** - Enhanced `save_result` function to store possible volunteer assignments with a `PENDING` status in the `ShiftRequestVolunteer` table. - Added exception handling and rollback mechanisms for better reliability in database transactions. 6. **Flattened Matrices:** - Helper methods were introduced (`flatten_compatibility`, `flatten_skill_requirements`) to flatten 2D matrices into 1D arrays for passing into the MiniZinc model. 7. **Miscellaneous:** - Removed unnecessary vehicle and position requirements that were irrelevant to the current optimisation scenario. - Refactored the entire `solve()` method for clarity and performance. **Testing:** - The MiniZinc model string was tested by running it in the MiniZincIDE with hardcoded inputs to validate the optimisation logic and constraints. Further testing for data persistence is required, particularly for interactions with the database. Since I am not yet familiar with this process, I need some guidance on setting up and using a database mockup. ## Issue ticket number and link ### Related Issue Tickets - [FIR-4: Scheduler Create Shifts](https://fireapp-emergiq-2024.atlassian.net/browse/FIR-4) - [FIR-111: Optimiser outputs optimal volunteers](https://fireapp-emergiq-2024.atlassian.net/browse/FIR-111) --------- Co-authored-by: Muhammad Hafizh Hasyim <u7316882@anu.edu.au>
fireapp-3.119.0-gh-readonly-queue-main-pr-294-e91734abe3309ab29bf330ca41a504e46f48d8c4.1
5oappy/feature/calculator v2 (#294) ## Describe your changes big one: removed vehicles and its ties to shifts, that will be handled separately via a flag in `shift_request` table. added `shift_position` which acts as a replacement for vehicles and essentially creates position slots for each shift of which volunteers can be assigned to, not very resource efficient I'm aware but it seemed the most object oriented way of doing it. work flow cant be thought of as: 1) "scheduler-user" creates a `shift_request` entry `shift_request` entry contains key information about the shift etc but specifically the `vehicle_id` flag which ... 2) triggers a function that adds the specific assignment and amount of `roles` required for the shift to the `shift_position` table linked back to the shift. The amount of positions and their roles types depends on the `vehicle_id` flag. (note this is not implemented in this pr but will be created soon [FIR-112](https://fireapp-emergiq-2024.atlassian.net/browse/FIR-112) ) 3) Then, the scheduler (`optimiser`) is called and it obtains all the info from the relevant tables: `shift_request, shift_position, roles` and extrapolates data into values that mini zinc can use. 4) mini zinc returns a 2d array of best volunteers for each shift as well as persisting them to the database table `shift_request_volunteer`. ( [FIR-111](https://fireapp-emergiq-2024.atlassian.net/browse/FIR-111) ) Other misc changes included: - Adding unavailability parameter to `user` table. - Changing the link to roles be through role.code instead of Id as it makes more canonical sense. BIG RISK as it might mess with mini zinc , `user_roles` and how we parse the roles types however it can simply be reworked. added unique flag to the code to ensure only one of each role type is ever created. - Commenting out the deprecated code of the original calculator. Ideally I should have set this up in a separate file (I still can, id just have to copy all local changes into a new branch in a separate file) I just happened to do it in the file as it was easiest to see which stuff impacted which directly. more details of the table linking logic at commit b099dacd3ddb4248ada633a35195f8559e540713 note theres is a conflict in this pr in the domain/entity/__init__.py just of notification stuff will be handled when prompted by GitHub. ## Issue ticket number and link [FIR-4](https://fireapp-emergiq-2024.atlassian.net/browse/FIR-4) [FIR-51](https://fireapp-emergiq-2024.atlassian.net/browse/FIR-51) note: its a tiny bit of a mess as I wasn't signed in and it wouldn't let me pr but I didn't realise so I went through a whole mess of rebasing origin/main into my branch before realising
fireapp-3.119.0-gh-readonly-queue-main-pr-294-cb6368e50d89ca86340f5e1589c4c038750adcdc.1
5oappy/feature/calculator v2 (#294) ## Describe your changes big one: removed vehicles and its ties to shifts, that will be handled separately via a flag in `shift_request` table. added `shift_position` which acts as a replacement for vehicles and essentially creates position slots for each shift of which volunteers can be assigned to, not very resource efficient I'm aware but it seemed the most object oriented way of doing it. work flow cant be thought of as: 1) "scheduler-user" creates a `shift_request` entry `shift_request` entry contains key information about the shift etc but specifically the `vehicle_id` flag which ... 2) triggers a function that adds the specific assignment and amount of `roles` required for the shift to the `shift_position` table linked back to the shift. The amount of positions and their roles types depends on the `vehicle_id` flag. (note this is not implemented in this pr but will be created soon [FIR-112](https://fireapp-emergiq-2024.atlassian.net/browse/FIR-112) ) 3) Then, the scheduler (`optimiser`) is called and it obtains all the info from the relevant tables: `shift_request, shift_position, roles` and extrapolates data into values that mini zinc can use. 4) mini zinc returns a 2d array of best volunteers for each shift as well as persisting them to the database table `shift_request_volunteer`. ( [FIR-111](https://fireapp-emergiq-2024.atlassian.net/browse/FIR-111) ) Other misc changes included: - Adding unavailability parameter to `user` table. - Changing the link to roles be through role.code instead of Id as it makes more canonical sense. BIG RISK as it might mess with mini zinc , `user_roles` and how we parse the roles types however it can simply be reworked. added unique flag to the code to ensure only one of each role type is ever created. - Commenting out the deprecated code of the original calculator. Ideally I should have set this up in a separate file (I still can, id just have to copy all local changes into a new branch in a separate file) I just happened to do it in the file as it was easiest to see which stuff impacted which directly. more details of the table linking logic at commit b099dacd3ddb4248ada633a35195f8559e540713 note theres is a conflict in this pr in the domain/entity/__init__.py just of notification stuff will be handled when prompted by GitHub. ## Issue ticket number and link [FIR-4](https://fireapp-emergiq-2024.atlassian.net/browse/FIR-4) [FIR-51](https://fireapp-emergiq-2024.atlassian.net/browse/FIR-51) note: its a tiny bit of a mess as I wasn't signed in and it wouldn't let me pr but I didn't realise so I went through a whole mess of rebasing origin/main into my branch before realising