This document defines the software requirements for the distribution point features for Reveal. A distribution point is a centralized location where individuals meet to receive care. The primary workflows are funded under a grant for Neglected Tropical Diseases (NTDs) which focuses on distributing medication among children who are attending schools in Eswatini. The functional requirements are outlined on NTD School Workflow and the data dictionary. This document applies those functional requirements into the Reveal technical architecture.
...
(Outside of the system) The user updates a template based on the structure that’s defined for the project
User logs into the system
User chooses a plan (draft or active)
User chooses a jurisdiction distribution that they want to upload the CSV
User clicks a button to find the file on their computer
User clicks the upload button and the CSV is uploaded to the server
Details are passed in with the CSV to show what types of entities to generate and the mapping of the template.
CSV is parsed server side and validated (See CSV Validator section)
An error is returned to the user if the CSV is invalid or it doesn’t pass a security check
An event is created for each row in the OpenSRP server
Each event is tagged to the plan and location
A task is created for each even that’s uploaded if the plan is active. Otherwise, tasks are created when the plan becomes active.
(Existing functionality) A client is created in the Android client for each event when it’s received
...
How do we roll back these items in the event someone messes up?
We need to define the logic behind generating
We need to define the error handling.
(Business question) Users don’t have a view into all of the entities that are registered to a distribution point. Therefore, they have no idea if their list was uploaded correctly. How should we mitigate this?
In other words, how will we handle mistakes when a user uploads information that they don’t want to be there. What’s the life cycle we should create to remove the likelihood of duplicates?
We need to come up with unique id generation so that we can
We are building a bulk event generator in this CSV upload process. It would be valuable to support JSON format as well as CSV.
We need to determine if we should have different variations of the template and optional fields so that we don’t need different templates here.
OpenSRP Web UI
We need to develop the following features in the OpenSRP Web UI in order to deliver the features above.
...
Users should not have the capability to download large lists that contain personally identifiable information about the clients.
Access to download rosters will, at maximum, provide identifiers that can be linked to people registered in the system.
All uploads need to be validated to include the following:
Valid CSV architecture with UTF-8 encoding
Individual fields are parsed and validated to remove exposure to SQL injection threats
Individual fields are parsed and validated to remove exposure to cross-site scripting threats
(We probably need to add more here)
Things to be discussed from scoping so far
...