Comment 5 for bug 1806623

Thanks for that - the query you have used isn't identical to what the shift reports will use to calculate as all dates/times in the database are stored in UTC.

I think what is happening is that very long calls are being recording in the database due to calls or call attempts not being closed, and then being closed the next day / time the operator is logging on. Can you please check the call attempt records or call records in the database where they are very long, and see if they are the "last" call attempt for that operator for that day/ shift?

If so, it is possible the operator is not ending their calls properly, or there is something else preventing the correct "end of call" code being executed.

If this doesn't fix the issue, an alternative may be to specify a "max" call time (eg 4 hours or so) and then update the end_call and end_call_attempt functions to record a specified call time if it is over this threshold. This would allow operators to not correctly end some calls but still have consistent data.