DRAFT: Route planning/handover support

[duckbytes]

Adds a tab to the task overview page for Routes/Handovers. Adds general route planning capabilities.

Can be used for internal journeys or originating hospitals when collaborating with other groups.

Add a handover point to the route and set the location from the directory.

Click the map to expand for a maps view.

Each handover has these data points:

• handover location
• status
• assigned rider
• time handover completed

Status could be PENDING (assigned but not yet picked up) > PICKED UP > DROPPED OFF > COMPLETED (rider home).

The first and last elements in the list are the first pick up and final delivery points.

Draft model for the schema:

type Handover
@auth(rules: [
  {allow: private, operations: [read]},
  {allow: groups, groups: ["COORDINATOR", "ADMIN"], operations: [create, read, update]},
])
@model {
  id: ID!
  tenantId: ID! @index(name: "byTenantId")
  task: Task! @belongsTo
  timeOfHandover: AWSDateTime
  handoverLocation: Location @belongsTo
  orderInGrid: Int!
  status: TaskStatus
}

Also add to Task model:

handovers: [Handover] @hasMany

TaskAssignee model:

type TaskAssignee
@auth(rules: [
  {allow: private, operations: [read]},
  {allow: groups, groups: ["COORDINATOR", "RIDER", "ADMIN"], operations: [create, read, delete]},
])
@model {
  id: ID!
  tenantId: ID! @index(name: "byTenantId")
  role: Role!
  task: Task @belongsTo
  assignee: User! @belongsTo
  handover: Handover @belongsTo
}

Piggybacking on the TaskAssignees model to record assigned riders to a handover, by adding a Handover relation. This means the dashboard only has to look at one datasource for displaying all riders tasks on their dashboard.

This would change the Task to non-required (on master current it is a required field). Could also add a new role to Role enum: HANDOVER.

I had considered using the same Task model for handovers instead of creating a new model, however this would mean duplicating data to keep records consistent (priority, contact information). It would also add unnecessary data points like time picked up, time dropped off, when only time of handover is required.

Uncertain how to handle assignments to the task itself, as depending on whether there are handovers, a rider needs to either pick up a job and take it to the delivery destination, or take it to the next handover point.

If a rider is assigned to the task their dashboard will display the task as if they were taking it the whole way. If assigned to the rider as a handover it'll show just their leg of the trip.

It could be that we should adopt the same type of assignment record for all rider jobs, regardless of if the Task has any handovers or not.

Code is still a work in progress and this is a draft pull request.

@ianphunt58 and @petersjtaylor can you provide feedback please?

[ghost]

Looking at the description I am not sure I see the need for a separate workflow for Handovers, at the end of the day, the destination is the Handover point, the rider will go no further. For the handover rider his job starts from the Handover point. Perhaps when creating Handover jobs, n job records need to be created for as many destinations as there are, 2 by default.

[duckbytes]

That workflow does work for the time being, but I think there are some benefits to adding relay support:

• Overall a better user experience, as it's easier to think of one job having multiple steps, rather than having completely separate jobs
• Better tracking: eventually I want to add a view that tracks the steps of a job. For external users they can see where their delivery is or has been. For volunteers they can look up a job in the past and see exactly each step of the delivery, which would be very difficult if the jobs were separate.
• No duplication of data. A job has the same urgency, contact details and time of call. Maintaining two separate jobs would mean trying to duplicate and synchronise any changes between those records. The drop off time would be the same as the pick up time of the next.

I also think the map feature would be a very nice one for visualising relays and seeing the distances involved.

[ghost]

That workflow does work for the time being, but I think there are some benefits to adding relay support:

• Overall a better user experience, as it's easier to think of one job having multiple steps, rather than having completely separate jobs
• Better tracking: eventually I want to add a view that tracks the steps of a job. For external users they can see where their delivery is or has been. For volunteers they can look up a job in the past and see exactly each step of the delivery, which would be very difficult if the jobs were separate.
• No duplication of data. A job has the same urgency, contact details and time of call. Maintaining two separate jobs would mean trying to duplicate and synchronise any changes between those records. The drop off time would be the same as the pick up time of the next.

I also think the map feature would be a very nice one for visualising relays and seeing the distances involved.

Ok, I can see a few use cases in your response there. Does the code support all of those use cases?

[duckbytes]

Ok, I can see a few use cases in your response there. Does the code support all of those use cases?

They can be supported. This will be a good starting point I think.

Looking up historical records is high up on my list of things to do too. I might pick that up quite soon.

[ianphunt58]

Not really sure if I should comment, way too detached now of the plan or the schedule or the status of any go live at Freewheelers.

Happy to get involved but need to know the structure now, it drifted away from me

Ian Hunt

Chair – SERV Herts and Beds

From: Peter SJ Taylor @.> Sent: 30 January 2023 11:40 To: platelet-app/platelet @.> Cc: ianphunt58 @.>; Mention @.> Subject: Re: [platelet-app/platelet] DRAFT: Route planning/handover support (PR #122)

That workflow does work for the time being, but I think there are some benefits to adding relay support:

• Overall a better user experience, as it's easier to think of one job having multiple steps, rather than having completely separate jobs
• Better tracking: eventually I want to add a view that tracks the steps of a job. For external users they can see where their delivery is or has been. For volunteers they can look up a job in the past and see exactly each step of the delivery, which would be very difficult if the jobs were separate.
• No duplication of data. A job has the same urgency, contact details and time of call. Maintaining two separate jobs would mean trying to duplicate and synchronise any changes between those records. The drop off time would be the same as the pick up time of the next.

I also think the map feature would be a very nice one for visualising relays and seeing the distances involved.

Ok, I can see a few use cases in your response there. Does the code support all of those use cases?

— Reply to this email directly, view it on GitHub https://github.com/platelet-app/platelet/pull/122#issuecomment-1408471500 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AYEX27YKVHPHXDZSB6CH4GTWU6SADANCNFSM6AAAAAATHAHZHQ . You are receiving this because you were mentioned. https://github.com/notifications/beacon/AYEX273UDKSQVIJPVGGLYF3WU6SADA5CNFSM6AAAAAATHAHZHSWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTST6OI4Y.gif Message ID: @.*** @.***> >

[Joetooker95]

I like the idea of being able to see a point by point tracking/ progress update screen and for the rider only to see their leg of the journey instead of the entire run to save confusion.