This document scopes the business logic required when resetting or deleting event data of a task. This event data will not be truly deleted, but it will be archived on the client and then stored as an archived event on the server side and will no longer appear on the UI in either the client or web. We can treat much of the logic here similarly to how we treat archived family and family members.

<I’m not sure if I should be talking about events or tasks, but I’m using events>

Jira Tickets Covered

https://smartregister.atlassian.net/browse/RVL-404

Reset (Archive) Event data

Affected Task Types:

• Blood Screening

• Case Confirmation

• IRS

• Bednet Distribution

• Mosquito Collection

• Larval Dipping

Tasks/Events will only be eligible to be reset if they meet the following:

• Not a family registration task type

• Not a family member registration task type

• Completion of task does not generate other tasks. Includes:

  • MDA Dispense

  • Family Reg

  • Family Member Reg

• Event data has not yet synced to server

• If the event cannot be edited, it cannot be reset/deleted

Archive Event Logical Flow:

• After completing a form/event, press the “reset/clear” button for an eligible task. The user will see a warning “Are you sure you want to clear all data associated with this event? You will not be able to recover this data and this task will be marked as incomplete.” Suggested UI below.

• Post-Clear Actions:

  • Remove any data from the fields in the task; when you reopen the task, all fields will be blank

  • Reset the task status to “Ready” and generate a new event (not sure about if we need to gen new event)

  • Reset the business status to ‘not visited’ and change the colour on the map and task list appropriately

  • Rerun any on-app indicators calculations and remove archived tasks from the numerator and denominator and add newly generated event to denominator.

  • Store the cleared data somewhere on the client (Is this necessary? I don’t know where this would be stored but wouldn’t need to be accessible to user on the client but good for auditing on the server side)

  • Archive the data.

• If the task is has code:"Case Confirmation" we may be dealing with a special case where the case confirmation was assigned to the wrong person.

  • Change the task status to "Cancelled"

  • Remove the target from the household

  • Generate a new case confirmation task at the operational area level

Delay Event Sync for affected task types

To allow for a time that a user can “reset” tasks, we should delay automatic event sync by 5 minutes. When a user manually syncs events, this will override the delay and all events will sync. This delay only applies to affected tasks types listed above.

Client UI (Views)

This requires the user have a way to access the “delete” or “reset” functionality.

For tasks in the family module (Blood screening, Net dist., in some instances IRS):

• Option 1 - Add an ‘undo’ button next to the pencil icon in the family task view

• Option 2 - Add ‘clear all data’ button in the form view, that you would access when you go to edit the form.

For location-based tasks not in the family module (PAOT, Larval Dipping, Mosquito Collection, in some instances IRS)

• Option 1 - add ‘undo’ button on list view, next to the task status button.

• Option 2 - Add ‘clear all data’ button in the form view, that you would access when you go to edit the form.

• Option 3 - Add an ‘undo’ button on the card view

For non location-based tasks (BCC)

• Option 1 - add ‘undo’ button on list view, next to the task status button.

• Option 2 - Add ‘clear all data’ button in the form view, that you would access when you go to edit the form.

For those tasks that are not eligible for reset, the ‘undo’ icon or ‘clear’ button would be grayed out.

Suggestion would be to implement Option 1, potentially to implement Options 1 and 2.

Web UI and reporting implications

There should be little impact on the WebUI because we are limiting this to events that have not synced to the server so would never display on the web. This information will not show up in the web UI dashboards, but though it's not actionable, it needs to remain available for auditing purposes.

• Events should propagate through the ETL process and show up in the data warehouse

• We need to review the queries and remove any archived families, family members, form submissions and tasks from the dashboards so they don't show up as real information <this was a task on the archive family scoping doc, so maybe has already been done>

• Superset users should be able to build a report that shows counts of the number of events archived.

The client-side indicators could be impacted if they are measuring against the tasks that are deleted.

• Rerun any on-app indicators calculations and remove archived tasks from the numerator and denominator and add newly generated event to denominator.

General Android Client Logic

• These changes should sync from the Android client to the server

• Archived events should no longer be considered in any sync activities between the client and server