Closed aaront closed 5 years ago
Hi Aaron, wouldn't this already be resolved by the commit to introduce support personnel into event logs https://github.com/nmfta-repo/nmfta-opentelematics-api/pull/189/commits/5ec9a501cd442b7c89de82066b390b70d28f6795 now already merged?
An event log with a pending edit needs to be presented to the driver as a pending edit request that would need acceptance from them.
In order to do so in an app, a request is made for all a driver's logs (logs by userId
), and then those marked as "Inactive - Change Requested" would need to be resolved (and we'd also display to the driver the name of the support personnel that made the request).
When it comes time to transfer a driver's logs to the FMCSA, we'd also add the support personnel whom requested edits to the FMCSA. Again, it's more optimal to query all driver's logs for transfer by userId
for purposes of compiling the ELD output file.
these changes are now in : Aaron's Improvements to Log Event #196
Hey @BenGardiner just wanted to follow up with the example about the "getting all logs by userId". This would also apply when querying for logs on our server-side DB connection; I was using that for an example for the purposes of some 3rd party that may want to build an application that directly interfaces with the OTAPI log event.
Retrieving imported Log Events internally by UserID (ie. getting all logs from our DB by user for the purposes of transferring a driver's cycle days of logs to the FMCSA) is a primary use-case, and would apply for imported logs too.
Complicated DB queries or extra processing on import to computer and return requested edit logs by vehicle for the time periods that the driver was using this vehicle could lead to worse performance and the potential for our data, for instance, being incorrectly imported into another TSP.
Thanks for taking a look!
Retrieving imported Log Events internally by UserID (ie. getting all logs from our DB by user for the purposes of transferring a driver's cycle days of logs to the FMCSA) is a primary use-case, and would apply for imported logs too.
I'm not sure it is a primary use case for OTAPI as it is currently envisioned. But this could very well be something for future versions of the OTAPI. I encourage you to log this as a separate issue for safe keeping.
Resolves #194