| | 3 | === Tasks === |
| | 4 | * Assign Task should: |
| | 5 | * separate out !Persons/Groups/Orgs |
| | 6 | * use an Assign method which allows viewing many attributes & Filtering...rather than starting with the Name |
| | 7 | * Task Chaining with Dependencies |
| | 8 | === Consumables === |
| | 9 | * Support Consumables |
| | 10 | * Option 1: Action Plan has separate section for Consumables |
| | 11 | * Option 2: Items section uses item_entity_id to be able to assign Assets or Consumables |
| | 12 | === Teams === |
| | 13 | * Support Teams |
| | 14 | * Option 1: Action Plan has separate section for Teams |
| | 15 | * Option 2: Personnel section uses pe_id to be able to assign Persons or Groups |
| | 16 | === Requests === |
| | 17 | * Support Requests for Consumables, Assets, People and Budget |
| | 18 | * [wiki:BluePrint/Requests/2.0 Blueprint] |
| | 19 | === Resource Assignments === |
| 24 | | * Assign Task should: |
| 25 | | * separate out !Persons/Groups/Orgs |
| 26 | | * use an Assign method which allows viewing many attributes & Filtering...rather than starting with the Name |
| 27 | | * Support Consumables |
| 28 | | * Option 1: Action Plan has separate section for Consumables |
| 29 | | * Option 2: Items section uses item_entity_id to be able to assign Assets or Consumables |
| 30 | | * Support Teams |
| 31 | | * Option 1: Action Plan has separate section for Teams |
| 32 | | * Option 2: Personnel section uses pe_id to be able to assign Persons or Groups |
| 33 | | * Support Requests for Consumables, Assets, People and Budget |
| 34 | | * [wiki:BluePrint/Requests/2.0 Blueprint] |
| 35 | | * Task Chaining with Dependencies |
| | 42 | |
| | 43 | Currently, we just record !Start/End times for resource assignments. This is suitable for Budget Tracking, but not for KPIs. |
| | 44 | We could increase this to several parts, along with ODO (Odometer) readings for Vehicles: |
| | 45 | * Time Requested |
| | 46 | * Start ODO |
| | 47 | * Time Departed Base |
| | 48 | * Time Arrived at Staging Area |
| | 49 | * Staging ODO |
| | 50 | * Time Departed Staging Area |
| | 51 | * Time Arrived on Scene |
| | 52 | * Scene Start ODO |
| | 53 | * Scene End ODO |
| | 54 | * Time Departed Scene |
| | 55 | ==== Start Ambulances-only ==== |
| | 56 | * Time Arrived Hospital |
| | 57 | * Hospital ODO |
| | 58 | * Time Patient Admitted |
| | 59 | * Time Departed Hospital |
| | 60 | ==== End Ambulances-only ==== |
| | 61 | * Time Arrived Base |
| | 62 | * End ODO |
| | 63 | |
| | 64 | Of course, all of these could be hidden for specific deployments if they want just a simplified subset. |
| | 65 | |
| | 66 | The ideal way of handling this would seem to be to fully automate, like this: |
| | 67 | * GPS coordinates for Trackable resources (Persons or Assets) are regularly uploaded automatically to sit_situation |
| | 68 | - along with any other attributes that are available (ideally, for Ambulances, this would include ODO & Fuel level) |
| | 69 | * When the Trackable is assigned to an Incident, then a watch is placed on that table |
| | 70 | * When the location matches a point of interest (staging area, incident, hospital), with whatever buffer we deem appropriate, then the Status of the Resource is updated ('Arrived at Staging Area', 'Arrived Hospital', etc), along with updating the Time & ODO for that status. |
| | 71 | |
| | 72 | Of course, we need the ability to do manual over-rides for if the tech isn't available (e.g. broken) |
| | 73 | |
| | 74 | === Other === |
