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