5oappy/feature/calculator v2 #294
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
… be generated for each new shift on shift creation. linked the volunteers to the specifc roles in adition to being linked to the shift table edited calculator so that files will be called properly.
1. One-to-Many Relationship between ShiftRequest and ShiftPosition: • A ShiftRequest can have multiple ShiftPositions. • A ShiftPosition belongs to a single ShiftRequest. 2. Many-to-One Relationship between ShiftPosition and Role: • A ShiftPosition can have only one Role. • Each role can be assigned to multiple ShiftPositions. 3. One-to-One Relationship between ShiftPosition and ShiftRequestVolunteer: • Each ShiftPosition is assigned to at most one ShiftRequestVolunteer, and each volunteer is assigned to exactly one ShiftPosition. this is to ensure that the database works as expected. will need to to be reworked in calculator -> get_skill_requirement and get_role_count.
This reverts commit dbef7d0.
|
Even though the linking logic is correct I think my implementation has missed some stuff so definitely DO NOT merge this yet, @BenMMcLean pls have a look at my failed py test and specifically the parts where it fails to reference the required shift table and offer guidance. it could be that the new tables haven't been added to the docker yet but I'm unsure. I gotta sleep now ping me and ill respond Sat evening or Sun, |
emilymclean
requested changes
Sep 30, 2024
- fixed shift_request.id reference in ShiftPosition - modifed ShiftPostion table name from position -> shift_position
emilymclean
previously approved these changes
Oct 1, 2024
github-merge-queue
bot
removed this pull request from the merge queue due to no response for status checks
emilymclean
approved these changes
Oct 3, 2024
emilymclean
removed this pull request from the merge queue due to the queue being cleared
github-actions bot
pushed a commit
that referenced
this pull request
Oct 3, 2024
## 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 b099dac 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
github-actions bot
pushed a commit
that referenced
this pull request
Oct 3, 2024
## 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 b099dac 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Describe your changes
big one: removed vehicles and its ties to shifts, that will be handled separately via a flag in
shift_requesttable.added
shift_positionwhich 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:
"scheduler-user" creates a
shift_requestentryshift_requestentry contains key information about the shift etc but specifically thevehicle_idflag which ...triggers a function that adds the specific assignment and amount of
rolesrequired for the shift to theshift_positiontable linked back to the shift. The amount of positions and their roles types depends on thevehicle_idflag. (note this is not implemented in this pr but will be created soon FIR-112 )Then, the scheduler (
optimiser) is called and it obtains all the info from the relevant tables:shift_request, shift_position, rolesand extrapolates data into values that mini zinc can use.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 )Other misc changes included:
usertable.user_rolesand 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.more details of the table linking logic at commit b099dac
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
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