Creating a Checkpoint Tour
Preconditions:
- Position exists
[POST] /checkpoint-tours
{
"name": "AB tour",
"specialInstructions": "Be careful when you approach all checkpoints.",
"account": 687,
"position": 382,
"status": "ACTIVE",
"gracePeriod": 45,
"estimatedDuration": 15,
"recurrenceType": "MONTHLY"
}
Refer to the existing API documentation for details on minimum required fields, deprecated fields and more.
Starting a Checkpoint Tour (Session)
Preconditions:
- Guard is in a position of the site with the tour
- Guard is clocked in
[POST] /checkpoint-tours/<id>/actions/start-session
{
"performedBy" : 1074,
"startedOn" : "2022-09-12T18:10:00+00:00"
}
NB: performedBy is an employee's ID, the employee starting the tour, so their employee.id value.
A session will have been created:
Scanning Checkpoints
[POST] /rest/v1/checkpoints/{id}/scan/
{
"scannedOn": "2022-10-31 11:02:00",
"scannedBy": 1404,
"longitude": "45.5019",
"latitude": "73.5674",
"tourSession": 1520,
"device": 600,
"reasonManual": "Manual scanning reason"
}
At this time we are only validating the following things:
- The checkpoint needs to be active
- The log for this checkpoint does not be duplicated
Required fields:
- scannedOn
- scannedBy
Ending a Checkpoint Tour
E.g.
[POST] /checkpoint-tours/131/actions/end-session
{
"endedOn": "2022-10-31 11:08:00",
"performedBy": 1404,
"checkpointTourSession": 1520
}
Expansion on the prerequisites for working with Checkpoint Tour Sessions
A tour must exist
/checkpoint-tours/38
A tour must have checkpoints
/checkpoint-tour-assignments?tour=38&fields=checkpoint,checkpoint.name,tour
Or error:
An Employee must exist
Employee is currently clocked-in (has active work-session)
Otherwise error:
Note on DateTime UTC
We save DateTime in UTC. But if users desire to include their timezone in the payload, they can do so.
If we had "startedOn": "2022-09-13T14:10:00-04:00" for tour start and "endedOn": "2022-09-13T14:16:00-04:00" for tour end we’ll have them saved in checkpoint-tour-session in UTC as expected:
If we had "scannedOn" : "2022-09-13T14:15:00-04:00" for checkpoint scan, we’ll have the value saved in checkpoint-scans in UTC as well:
checkpoint-tour-session-comments
[GET] /checkpoint-tour-session-comments?limit=10&sort=-id&session:isnotnull
{
"session": 467132,
"content": "'Recorrido perimetral............\n\nParqueos zonas de marcas Sotano S -100 Parqueo anexo gama siete,bodega Tabor Reimers todo en orden.\n\n*SIN NOVEDAD QUE REPORTAR*\n\nMarca ubicada en el generador de B3 no se realiza por trabajos de construcción. \n\nMarca ubicada en las escaleras del sexto piso Wework se realiza en horario nocturno.",
"id": 2368013
}
I recommend they search for session value is not null, because I noticed that they have tons that are null, which means there are comments without any linkage back to a session. They should work with us to figure out how there are orphaned comments in the first place. Also, I don't see a means of setting limits for results to be returned. There's no dates or anything, so they might have to first generate a list of tour sessions IDs, and then only look for comments for those tour sessions, maybe as a /batch/file process where the tour session ID is the lookup.
Null session examples:
{
"session": null,
"content": "Report emailed to: Sala de Control",
"id": 2368052
},
{
"session": null,
"content": "Report Approved",
"id": 2368051
},
{
"session": null,
"content": "Report Approved",
"id": 2368050
},