Triage missing data in Inspection Form

[LocalNewsTV]

Describe the Bug Users are submitting Inspections where some details are missing (Watercraft Journeys)

Expected Behaviour These fields should be enforced by validation (Though its known that the user can force close the application to bypass)

Actual Behaviour At least two records have been submitted where no previous waterbody detail was listed, on a High Risk entry.

Implications Due to the nature of the app, high risk inspections that are missing details could be potentially harmful.

Steps to reproduce

• In one case, force closing the application brings you back to a shift overview where a user could potentially submit a shift

Additional Details

• There has been longstanding issues in validation in the application
  • These were thought to have been mostly resolved in this past off-season changes
  • There is a long history of Inspectors bypassing validation checks and submitting bad forms

[LocalNewsTV]

This bug is not a new bug, but a recurring issue over several years

Exploratory Results

• Data loss is not suspected as a culprit in this work, but bad user data from inspectors
• Users can bypass validation checks if they closed the application from a shift, this would skip the checks being done
  • This was deemed an acceptable risk by SOs during the off-season development work
• Dug into API, found 0 validation existed, it was purely in the Frontend of application for users.
  • pulled MW into a call to confirm suspicions/ check for additional insight

Recommended Actions

• If we want to avoid lengthy user testing and potential app breaking, we can skip the iOS application and add validation to the API Only
  • It's surprising the API had no validation in place. Just a generic T function
  • We control the API Through OpenShift so Apple is not involved, and it runs independently of the iOS Application
• The handler returns an error that is viewable in the iOS App so there is some room for communication there
• There is a risk of duplicate entries, so care would have to be taken to avoid it, this was discussed with SO CM
  • Records persist after being created even if a later one fails, since they are all separate API requests. But there is no form of rollback action in case of failure. The frontend will not mark them as sent until every record completed successfully, so duplicates get formed in subsequent loads
    • Keeping in this in mind, It would always have been a problem if a connection were to have broken in the middle of an upload (however unlikely that would be)

iOS App sends each record individually as seen in the screenshot

Line by the line the flow is:

1. Get my information local to the database (for created by fields)
2. Create a shift entry and return the entry #
3. submit one Watercraft Assessment Report (WRA)
4. Submit the blowbys (Assuming these requests are potentially asynchronous
5. Submit another WRA (Repeat process for n WRA)

This path forward bears in mind the SDK still needs to be updated for iOS and we are currently in the On-season so while the app is still in a stable state, avoiding potentially breaking updates is a priority

State as of writing

• CM to talk to MB to see if action wants to be taken
• Seeing as action is likely user error, changes may not be implemented during the on season. Need SO MB to answer before actioning any work.

[LocalNewsTV]

For the technical person who falls back on this ticket:

In the Lucy database, the post request for Inspections is located in api->api_sources->sources->server->modules->forms->watercraftRiskAssessment->watercraftRiskAssessment.route.ts

The POST handler is createResource at this time located on line 96

• this.dataController.createNewObject(data, req.user) appears to be a generic function with no additional validation. It simply creates the entry, and is used for different POST requests as well
• throwing an Error will return that errors text to the iOS Application

Probably course of action is to add a validation function on line 97 that throws an error on failure, to communicate with the frontend.