User Scenarios
RapidFTR can be made operational in emergency situations in multiple ways
While RapidFTR can be used as a stand alone mobile application to start registrations in an emergency (without the need for a central server to sync data with); _the most practical (and likely) way to start would involve having RapidFTR installed on a netbook server (along with an external WAP(wireless access point) attached - [NOTE1]); along with RapidFTR installed on multiple Android mobile phones._
[NOTE1] - The smoothest scenario would involve a rapidFTR server instance being set up and deployed as a webservice, with appropriate DNS entries set up to allow mobile devices to connect to it via wifi/data connections (e.g. http://emergency7.rapidftr.com) -> however in an emergency it is far more likely that there will not be sufficient time for this overhead and instead we will rely on a local deployment to a netbook which will be sent out to the camp. Also, we can't always count on a reliable internet/data connection, so the netbook will have to have an attached WAP so that it can create it's own wireless network that the android devices can use to connect to the server and sync.
Please also refer to the recommended operational guidelines for implementors to understand activities that can be done as part of deciding to use RapidFTR in emergency response. Some of these activities include
- Deciding the hardware, hosting, phones and software environment
- Trying to familiarize yourself with RapidFTR - and review child registration forms (you can configure them), decide on roles and permissions that users will have
- Find a suitable point in time when RapidFTR can be installed on the mobile device, along with languages that will be made available
- Users can be set up in RapidFTR as an initial activity in quick response situation (by users themselves on the mobile, if needed)
The below scenarios try to explain the different ways in which users can sign up in RapidFTR and start registering children (and send registered child information to server)
Please access details of Security Approach between Server and mobile
In majority of cases, a field administrator in a camp will create an user, hand over the mobile to the user and ask the user to sync with the server over wifi - to verify that the user can sync to server subsequently.
When the user syncs for the first time with the server, since the User is already set up, the user will be provided with authentication DB KEYS in mobile and marked as Verified user
It may not be possible to make the netbook server become available over wifi or network as part of the initial emergency response every time we want to have a new user. In these cases, users will be able to sign themselves up as an UnVerified user.
If the field administrator and users are in touch, administrator can create the user on the server. When the UnVerified User on mobile syncs with server, server validates that the user has been setup and marks the user Verified; moving their child registration data from UnVerified database to Verified database and providing them with encryption keys.
The user will be a Verified User from this point in time.
The two primary objectives of RapidFTR are to ensure user is able to start registering children at the earliest and to be able to share registered child records. RapidFTR server is the primary medium through which registered child records are shared.
Hence, any UnVerified User must be able to send their registered children records.
In most cases, even if the user started by signing up as an UnVerified User, they would have communicated this to the field administrator and the user would have been created on the server.
However, even if they have not been setup, when the UnVerified User first syncs with the server, RapidFTR will create the UnVerified User in the server and accept the child records.
The user and child records will be placed in UnRegistered Users Queue for review. The UnVerified User and child records will be marked Verified on field administrator approval.
The UnVerified User will be sent their authentication DB KEYS and moved to Verified database in mobile the next time they sync with server. Any residual UnVerified Child records on the mobile (registered after the earlier sync) will be moved to the Verified database and sent to server in the next sync.
Note: All UnVerified Children records on the server will be shared with Verified Users through the Search functionality (sync'd with all Verified Users)
Scenario implemented via stories #1494 and #1514
4. User signs up as UnVerified User,has been set up in Server with a different password; logs in to mobile with server password (online)
Unlike previous scenarios, it is more likely that when an UnVerified User signs up in mobile and requests the field admin to create an account for them in server - to make them a Verified User; the field administrator could create the user with a different password and give the password (outside of RapidFTR) to them.
An UnVerified User who has been provided with a Verified User account can login to the server when online. In these cases, RapidFTR internally moves the registered child records on the mobile to the Verified database and syncs with the server
These scenarios deal with a slightly more hazy operational setup - where user names are likely to be duplicates. As understood during the build of RapidFTR v1 and v2 versions, User Names are less likely to be duplicates.
Operationally, there are organisations involved and they like to be able to identify an User Name to a single user. Hence, in all likelihood, duplicates could come because of exceptions rather than having to be dealt with as the norm.
With these inputs, design of RapidFTR allows an approach to quickly sync child registration information and at the same allows the flexibility to tighten processes to require manual review and acceptance during occurrence of duplicates.
These scenarios may be built as we get more feedback from initial pilots on the field.
5. User signs up as UnVerified User, another Verified User with same user name logs in, before UnVerified User has sync'd even once
Similar to (4), an UnVerified User signs up on the mobile and registers children. Meanwhile, some other user, chooses the same User Name as the UnVerified User and gets created as a Verified User on the server.
And, gets the mobile that the UnVerified User was using to register children. To add, the UnVerified User never managed to connect to the server (for ex: network was not available until after the Verified User got the phone)
Under these circumstances: UnVerified User having the same user name as Verified User and having child data not sync'd with server..when the Verified User logs in, if we go with the approach in (4), the child records will be attributed to the Verified User who has successfully logged in to server during the login process
To prevent, a solution is, RapidFTR will
- Verify if there is an UnVerified User with unsynced records
- And if so, prompt the user to choose if they want to login as the UnVerified User or Verified User; check appropriate password and allow them access.
6. User signs up as UnVerified User, syncs with Server, another user exists with same User Name on Server
In this case, an UnVerified User who has signed up and registers children find that when they sync, unlike (2) - where the field administrator has already created their Verified User Name with same password; another user has already taken their User Name.
RapidFTR will be able to detect this conflict and during the sync, request the UnVerified User to select a different User Name. It is proposed that the list of user names be sent to mobile if this condition occurs - so that uniqueness can be established as much as possible, without back and forth network traffic.
After the UnVerified User selects another user name, RapidFTR will process according to (3). The UnVerified User will be kept in UnVerified Queue pending Field Administrator review.
(This scenario is likely to be developed only after we get additional field input on whether this is actually required)
###7. Users with same User Names exists across Servers. This is found out when servers are sync'd with each other
In an emergency, RapidFTR may be independently set up across multiple physical locations. Each of these locations could be catering to the same emergency and have affected people and response team moving between them.
RapidFTR v2 will allow child registration data to be sync'd across two different servers in different physical locations.
- If the servers in two physical location are connected directly over network or connect to a third server over network, data can be replicated.
- Alternately, a travelling netbook can connect to netbook server in a camp using its wifi access point and replicate all registration data.
At this point in time, the operational assumption is that Verified User Name across these camps will be unique. The data that will make this unique needs to be clearly established - for example, it could be re-confirmed that user name will suffice, or, a different combination, like, User Name/ Full Name and Organisation combination, may be required.
Also, operationally, it will be recommended that RapidFTR field administrators review user names at least once, prior to replicating data between servers. This could be aided by a physical report of users shared across camps, until the servers share data with each other.
RapidFTR proposes to eventually build functionality that will allow administrators to change User Names for existing users. This will let potential conflicts be resolved by changing the User Name for one of the duplicate(s). This change in User Name must also be reflected as part all registered children's history - to allow auditing of child record changes to be effective.
*Note: An alternate solution that was also thought of was to capture all registration data based on User Id - a system generated random number, that is guaranteed to be unique. However, moving to User Id based registration data capture will require changes across many well tested and working parts of the application built over more than two years. The value for introducing this design change is not very clear.
So, as a next step in the future - it may suffice to build a functionality that will let User Name be changed. This functionality is any way required, since, on the field, there have been reported cases of the same user inadvertently having two different identifiers and a need to remove one of the user names and merge with another.*
In the current implementation, it is possible to switch between instances by specifying a different URL. This works even when the different instances share a username.
For example, given the following instances:
| Instance Name | Existing Users |
|---|---|
| https://instance1.rapidftr.com | user1, field_worker |
| https://instance2.rapidftr.com | user2, field_worker |
Online operation
- If user1 or field_worker logs into the mobile and specifies the instance1 url, they are able to log in and see (and manipulate data for only instance 1)
- Similarly, If user2 or field_worker logs into the mobile and specifies the instance2 url, they are able to log in and see (and manipulate data for only instance 2)
- If user1 attempts to log in with the instance2 url, or user2 attempts to log in with the instance1 url, they are presented with the error message
Invalid Credentials
Offline operation
- For the distinct users (user1 and user2), offline login will always present the user with the data from their instance
- For the user field_worker that shares a username across instances, the operation is such that logging in offline with this username will present the user with the data from the last logged-into instance
Syncing
- A peculiarity is that selecting
Synchronise Allalways attempts to perform the sync against the last logged-into instance. This means that if instance1 was the last logged-into instance, and for some reason user2 is able to log in offline, then when user2 logs in they will be presented with the data from instance2. When user2 selectsSynchronise Allthe mobile will attempt to perform the sync against instance1. Fortunately, from testing, this results in a session expired error, requiring user2 to first log in online (at which point they will have to specify the correct instance).