UI:
Using react admin. Fields - Name.

API:
New api needs to be created which will create encounter type and operational encounter type.

As an org admin, I want to be able to create a concept inline when creating a form element.

Mockups:

The flow when you are adding a new element and want to choose an existing concept for it:

The flow when you are adding a new element and want to create a new concept for it:

The key idea behind these mockups is that we are telling the user explicitly that you have to choose or create a concept when you create a new element. Another main idea is to have a separate box for the concept in the element so it's obvious as to what the concept fields are and what the element fields are once the concept is created or chosen.

Test Scenarios -

• Create a new question with the new concept.
• Create a new question with an existing concept.
• Create a new coded type question with the existing concept for question and new coded answer.
• Create a new question with the new concept but that concept already exist in the system (it should give an error).
• Create a new concept and use this with existing coded answers.

App logs out on refresh.

Location -> select a location with children -> Click on Edit -> Click on delete -> It gives message "Element Deleted"
After few seconds it gives the message "Cannot delete this location until all the sub-locations are deleted".

"Element Deleted" message should not come.

Acceptance Criteria:

• User should be able to change the display order of form element and form element groups using drag and drop.
• When a question is dragged to another place in the same group then we should change the display order of that element and all other elements after it.
• When a group is dragged to another place then we should change the display order of that group and all other groups after it.
• When a question is dragged from one group to another then we should void the question from the source group and create a same question with another uuid into destination group.

This story will implement the search functionality in DataEntryApp.

In scope

• Registration and enrolment through the search screen
• Automatic addition of scheduled visits
• Implementations specific changes to worklists.

1. Login.
2. From any listing open an item. Go back to listing.
3. Leave the tab open till your session expires (depends on the token expiration policy we have in Cognito). This basically simulates use case when people stay logged in, use tabs and work regularly using web app.
4. After the session expiration, try to open an item in the listing.

Expected - The user would be logged out and brought to the login screen.
Actual - It tries to open the item, fails and goes back to listing. No feedback to the user that they need to log in.

Functionalities:

The Search API provides pagination and sorting. However, the UI does not allow pagination or sorting in the results. This story is to provide these capabilities within the app.

The UI needs to be similar to how sort is implemented in the admin UI for consistency between admin and data entry apps.

The subject dashboard is a place that provides a snapshot view of a subject, and the different actions that can be taken for that subject. Capabilities include

• View subject registration details
• View subject enrolment details
• View enrolment summary rules
• View checklists for a program
• Create new visit
• Edit visit
• Cancel visit
• Add checklist
• Exit from program
• Add or remove relationships

We have parentId in AddressLevelType but we don’t have it on Webapp UI so add it on UI.

In Create/Edit forms, add Parent field

QA Comment – 

• A location type is tagged as a parent for another location type. Now if you delete the parent location
type, It will be still tagged with the child location type. for eg: Check location type- Block. 

!Screen_Shot_2019-06-19_at_3.17.02_PM.png!

• Not able to create a location type “District” Level – 4. Error msg – Server communication error.
• In edit option, it gives the option of editing Parent also. But parent cannot be changed.

Scope

We will migrate implementations that we want to demo to UI based rules.

Tasks

• calls to classes like RuleHelper etc will either have to be provided as library functions or have to be inlined as nested functions.
• libraries like moment and lodash to be injected as function parameters.

Don't allow to void location type before voiding it's children.

https://docs.google.com/spreadsheets/d/1cVy2Lz1_A9f8RP3HhNUfvbCkrgMjA4k4nUy6Figx5NI/edit#gid=2134823698&range=D13

QA Comment -

• It does not allow to delete the location but at first it gives the message that element deleted and after some seconds it gives the error message that "location cannot be deleted......".
It should give the error message as user click on the delete button.

QA Comment -

• Refresh is not working on the search page. [fixed]
• In which order list is sorted. [separate card exists for sorting]
• Can we have some filter also and on top of that we perform the search? [create a separate card if this suggestion converts to a requirement]
• Also, mention somewhere what is the list about. [Not clear what needs to be fixed]
• For waterbody, subject type list is not appearing. Username - dhakaneka@ddm. [fixed]
• Does not tokenify names (search for "sushma thakur" and "thakur sushma" must give Sushma Thakur) [create a separate card for search imporvement]
• Enter key does not work to search [it works]

On login, if a user is not an org admin, (s)he will be taken to the search screen. Search screen should have the following.

1. Logout button
2. One search field (text input) and a search button
3. Search results with the following parameters.
   a. Name
   b. gender (if individual)
   c. Date of birth (if individual)
   d. Location (full location in the form of A->B->C)
   e. Programs enrolled
4. Search results will always be shown by default without starting search.
5. Search results will be limited to the catchment of the user.

Out of scope:

1. Pagination. Separate card exists for search page improvements.
2. Granular filters. ex: Gender, Active Programs.

Tasks:

• On choice of datatype, show different ui for each type.
  • Common fields are name(string(255)) and dataType.
  • Numeric - Show form fields for Low Absolute(number), High Absolute(number), Low Normal(number), High Normal(number), Unit(string)
  • Text
  • Notes
  • Coded - Show an autocomplete field for Answers. It should call API on typing to get matching concepts. Also functionality to quickly add new concept to be used as an answer.
  • NA
  • Date
  • DateTime
  • Time
  • Duration
  • Image
  • Id
  • Video
• Finally when all the details are filled user will click on Save button which will call POST /concepts API.

API will expect below format:

• For Coded concept

  {
    "name": "Block",
    "uuid": "87e1989a-c690-4385-b3da-e6e1bacc8f85",
    "dataType": "Coded",
    "answers": [
      {
        "name": "Sagbara",
        "uuid": "833d9b73-1743-424e-8b0e-0de05b69ca4a"
      },
      {
        "name": "Nandod",
        "uuid": "8f7befa1-2cc5-4189-9f67-1fd1953ab720"
      },
      {
        "name": "Tilakwada",
        "uuid": "236c7984-4176-45e3-819b-992a39e2a3a4"
      }
    ]
  }

UI:
In the form listing page - In action column there will be a button called copy for each records.
Once user click on the copy button of the appropriate row a pop-up will show-up. This pop-up will ask for name, an encounter type and a program. On confirmation it will create a new form with different name and form mapping but same groups, questions, and rules.

API:
New API need to be created which will clone the form server side.

Tasks:

• Add Create New Group button - 1
  • Will be located outside group section
  • Should add a new group section below an existing group
• Add Create New Question button - 1
  • Will be inside group
  • Should add new question below last question
• Expand/Collapse for groups and questions - 0.5

In scope

• Show checklists
• Fill in form for checklists

Admin user should not be able to disable itself and should not be able to change itself to normal user

As a field service user, when I am on the search subject list page, I need to be able to register a new subject.

In scope

• Basic Registration wizard with all form element types for any subject type
• Mandatory validation
• Regex validation
• Form element filters
• New Registration
• Edit Registration

Out of scope

• System recommendations
• Scheduling visits

Notes

1. Fetch all reference data - concepts, locations, genders, operational subject types, operational programs etc during initial load
2. Ensure these are not fetched every time using http cache
3. Extract openchs-models into its own npm repository. Use this as a dependency

In scope

• Calculated fields (EDD etc)
• Visibility filters
• Form element groups that are empty will be skipped
• When a field is removed from view, then its value is removed

Notes

• The following will be injected into the javascript loaded from the server
  • log
  • common
  • motherCalculations
  • models
    See avni-client/RuleService.js for more details.

In scope

From the search screen, the add button must take you to a listing of different subject types. Clicking on appropriate subject type takes you to the registration screen.
Registration screen must contain the following types of form elements.

• Numeric [done]
• Text [done]
• Notes [done]
• Date [done]
• DateTime [done]
• Time [done]
• Duration [done]
• SingleSelect [done]
• MultiSelect [done]

Out of scope

• Form elements Image, Id and Video
• Storing of location
• Validation (mandatory, range, regex)
• Implementation hooks (visibility filter, calculated fields, decisions)
• Ability to choose address of the Subject ( a separate card is there)

Notes

• Use openchs-models for data
• Keep reference data in memory

Workdone

date of registration should be current date by default - [done]
date of birth should have age - [done]
test with multiple subject types - [done (almost)]
multiple form element groups - [done]
add previous button on first page of form - [done]
other field types - [done]
handle non Duration FormElements [done]
fix underline in previous and next [done]
tests for new adapters for operational modules [done]
remove Linebreaks in SubjecrRegister

Catchment List -> Click on catchment -> Gives error "Something went wrong".
It is behaving randomly. This is not happening everytime. This was happening for JSS but might be happening for others also.

Introduce organisation short name in organisation table. In webapp use this to append @{shortname} postfix to username.
https://docs.google.com/spreadsheets/d/1cVy2Lz1_A9f8RP3HhNUfvbCkrgMjA4k4nUy6Figx5NI/edit#gid=2134823698&range=D3

UI:
using react admin. Field - Name

API:
Needs to be created which creates subject type and operational subject type.

Currently, we are showing only the highest level location list in the Location list.
So we need to search in all locations

API for search is /search/concept?name={value}

Tech:

• UI component for listing can be https://material-table.com/#/

Motivation:

As an data entry operator, the system should validate the data being entered in the forms before Save

Acceptance criteria

• When a validation fails, field is highlighted in red
• When a validation fails, user is not allowed to go to the next page and apt message is shown to the user
• For default fields in forms in application, validations given on technical details below link1 should work. eg: default fields: basic registration details: First name, last name, age, gender, date of registration, date of birth.
• For custom fields configured on forms:
  • All types of fields in the form such as (Numeric, Text, Notes, Coded, Date, DateTime, Time, Duration) should be validated based on the form configurations.
  • Configuration can be done on forms through admin app (regex and description key ) for any custom validations
    Example: Form, text element will have regex configured for validation for allowed characters and validation description key for error to be shown. If regex is not matched then we highlight the field in red and show an error given in the validation description key.
    Another example: Numeric concept will have low absolute and high absolute specified. If the value entered by the user is below low absolute then an error message with key numberBelowLowAbsolute should be shown. If the value entered by the user is above high absolute then an error message with key numberAboveHiAbsolute should be shown.
• Below Validations are in scope for different field types:
  • Mandatory validation for all types of fields (Numeric, Text, Notes, Coded, Date, DateTime, Time, Duration)
  • Numeric validation
  • Coded unique validation
  • Range validation for absolute min and max
  • Highlighting of values that are beyond the acceptable range
  • Regex validation
    ( Please see link2 in technical details for form elements validations that should work )

Technical Details:

All of this validations code is already there in particular avni model and you are supposed to just reuse it instead of writing all these validations from scratch. Use the validate() method of Individual model and FormElement model to validate the user data and get back the validation results. You only have to implement rendering the validation errors returned by the model and stopping the user from going to next page.

( as discussed and given by Hiren )
For default fields - like on registration basic details , Validations in code exist here:
https://github.com/avniproject/avni-models/blob/ac5e4209b70777f5f1682bb8cd308f7dc37d22ad/src/Individual.ts#L326

For other validations from form element:
https://github.com/avniproject/avni-models/blob/ca82d057567d1f49f709144f8000693a8063ea28/src/application/FormElement.js#L88

• Edit - 3
  • Pre-populate groups and questions data.
  • GET call for form details data

Acceptance Criteria

• Allows user to enter form type, form name, and other details.
• For the form types: ProgramEncounter, ProgramExit, ProgramEnrolment, ProgramEncounterCancellation it should ask the user to select the program name.
• For the form types: Encounter, ProgramEncounter, ProgramEncounterCancellation it should ask the user to select Encounter Type.
• Form name and Subject type are mandatory for all types of form.
• Redirects to form edit page after creating the form.

Mockup

Implementation details:

Move Form Type to be the first field of the form.

Add a new field for Subject type.
Subject Type, Encounter Type, and Program dropdowns should get populated from /web/operationalModules API.

Call the POST /forms on click of Create Form with all the details. Generate and send form uuid along with other parameters like form name, subject type, encounter type etc to the API. Once the form is created then navigate the user to form details page. API needs to be modified to take subject type, encounter type, and program name.

Create new Location -> Save -> Open list of location -> Location is not listed in the list.

Tasks:

• Listing forms
• API also needs to be changed because current /forms api returns only program related forms and not forms like registration or individual encounters.

• New
• Edit

UI:
Using react admin. Fields are Name, color(color picker) and subject label(hint same as name).
Way to define rules at program level : Program summary rule type.
Note : Current we use color name and not hex code so this need to verified.

API:
New combined api needs to be created which acts as a single resource for both operational program and program. API Url can be /web/program.

Resource structure is as follows:

{
  "name": string,
  "colour": string,
  "programSubjectLabel"
}

• Two tabs inside question - 3
  • Question details
    • Search for concept
      • On selection it will show UI depending on data type. Similar to current design.
  • Settings
    • UI to add a rule related to a form element

Tasks:

• Add fields form type, form name, subject type, program name, encounter type. For this use the same component as Create New Form. If necessary refactor code to extract out the common component.
• For rules
  • Give a UI to add new rules with rule type(Decision, VisitSchedule, Validation) and rule function(string). We can give add button to add new rule.
• Call the PUT /forms API on form save.

Two cards to navigate to react admin and the form designer.
Left menu component :

1. Add left menu to the form designer where we will be listing concepts and forms.
2. Refresh to take to same menu.

For every web user, there will be a profile section where all the information about User will be mentioned that we can see in admin login (but in this case user will be able to see only his/her info).

Right now there is no way to know which user is logged in.
Display user name somewhere in the app.

QA Comment -

• In profile it shows the username and Logout, it does not even says that if this is username or what.
(https://images.zenhubusercontent.com/5d0a151d5af8b352a1b5784b/b3cdca45-f5d0-4593-a953-69239c83c760)

Steps to reproduce:

1. Make sure there is only one non-voided location_type exist.
2. Go to locations -> create.
3. There won't be any input for parent location. [as expected]
4. When you save, it fails.

Rough idea on why it fails:

• even though there is no parent location. the payload to the location api has a parent object.
• It is {uuid,title,level,type, parents=[{}] }. But it has to be {uuid,title,level,type,} or {uuid,title,level,type, parents=[]}

Problem

Today doing an Avni implementation is not very intuitive to anyone outside of the product team. The metadata creation is tech heavy. It requires quite a bit of training on how an implementation is to be done and knowledge of json, sql and unix.

Solution

To fix the metadata problem, we have already started building the admin UI. Most of the metadata creation (users, locations, catchments) is available there, the only last thing being the ability to design programs, forms and the custom logic required for skip logic, calculated fields, visit scheduling and configuration other extension points available through code.

In scope

• A UI from which following can be designed
  • Programs
  • Forms with rules
  • Checklists

Out of scope

• Self service UI for tech organisations to host on existing hosted solutions
  This will require features like Database and reports access for partners, Log access for implementers, Server status available publicly, Ability to export and import data from an organisation, Migration of all existing rules to the new format

• Self service UI for end users
  Self service UI. The current purpose is not to have any organisation coming in and designing things for themselves. This is a good to have, but means that we need to integrate invoicing, emails, build a different kind of authentication, a lot more automation etc. The current objective is to be able to open up implementations to partners only. Opening it up to the general public will depend on how this goes. Partners will be empowered to handle data for their own organisations.

• Translations from UI [Being done part of a separate epic]

Challenges

• We might need to move away from hierarchical organisations to single organisations, and encapsulate data within each.

User flow

The deployment workflow will be managed through organisations. The implementers would be able to create organisations for QA, UAT and production. Metadata from one organisation to another will be promoted through an export-import mechanism.

Tech choices

• We will replace the uniqueness constraint on uuids on every table, and replace it with a combined constraint on uuid and organisation.
• We will move javascript logic from the file system, break it down and attach it to where they belong (form elements, program etc). This can be either done in the same table, or in a common different table where all rules are stored. This also means zero imports/dependencies like what
• We will move away from hierarchical organisations to single organisations.
• We have not solidified any restrictions we need to provide from test to production.
• Import/export will reuse existing endpoints, and will be idempotent.

Acceptance Criteria

• It should export all the entities that can be created from UI designer and admin app as a single zip file.
• Directory structure: Flat files for all entities inside bundle zip. Forms will have it's own directory named forms. Inside forms directory store each form by it's name.
• All exported entities should have all attributes specified via UI Designer
  e.g. If an entity is voided it must have voided attribute set to true. Deleting existing form element, form element group, program, encounter type, subject, concept, concept answer results in it being voided.
  e.g. The numeric concept must have lowAbsolute, highAbsolute etc if they are set.
  e.g. Coded concept must have answers if they are set. Answers must have unique, abnromal if set.
• Parent addressLevelType should come before children addressLevelTypes in addressLevelTypes.json.
• Parent location should come before location in locations.json.
• In concepts.json: concepts that are used as answers in other coded concepts should come first. Concept answers in coded concepts should be ordered by order property of answer.
• form element groups and form elements inside each group should be ordered by display order.
• All exported files should be importable on both fresh database as well as an existing database.

Tech tasks:

• Entities to be exported
  • Form
  • FormMapping
  • Catchments
  • Concept
  • Location Types
  • Locations
  • Programs
  • Encounter Type
  • Operational Encounter Type
  • Operational Programs
  • Operational Subject Types
    • Translations
    • Organisation Config
• Create an API that will return zipped bundle file.

Mockup

Checklist Builder

• Checklist Form <dropdown that allows to choose form of type ChecklistItem>

Items (Option to add items)
Item (Option to remove item)

• Concept <autocomplete with NA concepts>

• After how many days of birth should it be scheduled? <number>

• Can this item expire? <yes|no>

• Expires after how many days from birth date? <number>

• Do this item depend on any other item? <yes|no>

• Dependent On <autocomplete or dropdown with items defined previously>

• Minimum Gap From Dependent (days) <number> //show only when this item depends on other item

Implementation Details

You need to call POST /checklistDetail api to save the checklist.