Currently we the following possible statuses for a request:
New,
Assigned,
Completed,
Canceled
These belong to the request object.
In the context of a single request to itinerary mapping these feel reasonable but in the case where a request is assigned to Itinerary 1 but not completed (door not answered) it should go back into the pool for assignment to a new itinerary.
This means we need to ensure that the statuses reflect these cases. I therefore propose we use unassigned rather than new.
When added via API a request is unassigned. When linked to an itinerary we expect it to be updated to assigned. If it is completed during that itinerary it is marked completed and status is updated. If not completed it is marked as such by the volunteer and this triggers the status to return to unassigned. Finally if a request is no longer required cancelled still seems valid.
@tonysurma @MisterJames - Does this sound reasonable to you both?
As an extra to this I wonder if we should include some more history around the request status. Perhaps a table to track the history (created, assigned, unassigned, completed, cancelled, failed) so that organizers can review this information to determine actions for difficult requests? Failed in this case could require input from the volunteer with a note explaining the issue. Perhaps the homeowner did not answer, perhaps they changed their mind, perhaps they ran out of equipment etc etc.
Currently we the following possible statuses for a request:
New,
Assigned,
Completed,
Canceled
These belong to the request object.
In the context of a single request to itinerary mapping these feel reasonable but in the case where a request is assigned to Itinerary 1 but not completed (door not answered) it should go back into the pool for assignment to a new itinerary.
This means we need to ensure that the statuses reflect these cases. I therefore propose we use unassigned rather than new.
When added via API a request is unassigned. When linked to an itinerary we expect it to be updated to assigned. If it is completed during that itinerary it is marked completed and status is updated. If not completed it is marked as such by the volunteer and this triggers the status to return to unassigned. Finally if a request is no longer required cancelled still seems valid.
@tonysurma @MisterJames - Does this sound reasonable to you both?
As an extra to this I wonder if we should include some more history around the request status. Perhaps a table to track the history (created, assigned, unassigned, completed, cancelled, failed) so that organizers can review this information to determine actions for difficult requests? Failed in this case could require input from the volunteer with a note explaining the issue. Perhaps the homeowner did not answer, perhaps they changed their mind, perhaps they ran out of equipment etc etc.