Form Configuration


Responsible team memberPierre Dane
Current Team Member
StatusIN PROGRESS
Targeted release DateJune 15 2020
Scoping Complete Date

February 28 2020


Jira Issue RVL-194 - Getting issue details... STATUS RVL-957 - Getting issue details... STATUS
LOEXXL
PriorityHigh

Status

#

Step

Status

1Responsible prepares rough business analysis/reqs docIN PROGRESS
2Get CHAI review
3Get Akros Review
4Get Ona feedback


5Responsible - 1 iteration for feedback


6Ona sign off
7Ona tech spec scoping
8Ona LOE 
9Ona scheduling

Business Requirements

  • As a system administrator, I would like to be able to create and update Reveal forms without needing to compile and release a new APK
    • Changes will include new form fields, hiding of forms fields but not updates to existing form fields (e.g. data type or the meaning of the form field)
    • Changes can include modifications to calculated fields, and changes to skip logic
    • Changes will also include the workflow rules for task generation based on form actions (Dynamic Tasking in the Client
  • There should be a UI for form development 
  • Forms will be authored and updated in the undelaying JSON documents 
  • Changes to form fields should be reflected in the data warehouse
  • The forms available to each implementation should be configurable
  • Form changes should be immediately testable in a realtime test application (as opposed to Android Studio or other IDEs where code needs to be compiled)
  • A minimum dataset should be defined for each form which will be used for dashboard reports and should not be changed

Definitions

Mock-Ups


Views


Justification


Dependencies


Notes

Supported:

  • json form editing

  • documentation support to edit json forms

  • web interface for uploading jsons

    • support download of existing forms (jsons) as a starting point for editing

    • user warning when form is incompatible with format at upload

    • other user warnings?

  • editing existing forms that have already been linked to activity → task → location

Not supported:

  • web-based form builder

  • creating new forms

  • ‘unbreakable’ forms - user will be able to remove certain fields on forms that may break the system (i.e. could remove ‘household head name’. Documentation and guidance will be written to avoid this, but the system cannot perfectly control for this.


add form definition upload

individually version forms and link to tasks

Ability to sync form definitions from server to client

Define minimum dataset and linked to task codes

link form definition version against the event

mange change over time for reporting

NO EDITOR - possibly use Enketo (there is a converter in progress for xls to json form)

Will need a manifest that tracks compatibility between form versions and apk versions - so that APK can only download forms that it is able to run

Need some way to test the json files - use a test android apk that can read forms from a web link or filesysyem

need to be able to download the json file for editing

ETL

Needs to use form definitions

e.g. Wanting to add more business data

Some cases wont affect business status (sleeps outdoors), some cases will (differential status depending on what done in the form - additional business data may do this) . Need to work within the existing business statuses. Can change the business status using calculation rules e.g. Bednet distribution - specify number of people sleeping in the house - external data )

Business status is calculated in the form, passed to the task.

Another example

For larval dipping and mosquito collection, there is no business data. If business data changes the task status, then will require coding


Questions

Nathan Mceachen
December 24, 2019, 2:21 PM
Hello everyone. I have some clarifying questions. For this requirement:

1) Will a user be able to define an entirely new form by uploading JSON or will they only be able to modify existing forms?

2) To what extent will the Reveal Android code need to be modified per country implementation? My understanding is that there is branching logic in the Android code that is custom per country (please correct me if I am wrong). I would think that as a part of this requirement that no custom Android code would need to be written for an implementation unless such implementation had unique requirements. The JSON should specify everything the Android client needs.

3) Where else will changes need to be made to Reveal other than the JSON for customizing the application? We (TerraFrame) has not gotten into the details of the reporting stack (NiFi/Superset), but will adding a new field to the JSON require additional changes to the reporting stack as well?

Test Case

#

Step

Pass / Fail

Comment

1




2




3




4




5




6




7




8




Additional tester comments: