Flexible Hierarchies - Fetching new places in the XFORMS

NOTE: This is a public repository. Images or logs containing protected health information (PHI) must be fully-redacted.

Describe the Bug
After successfully configuring a new place level, getting an error when attempting to load the UUID of this level on a contact creation form. E.g When creating a Health Center (now a child of a Supervisor Area level of contact_type supervisor_area and type contact).

ERROR
pyxform.errors.PyXFormError: Unknown question type ‘db:contact’.

How To Reproduce The Issue

  1. Create a Supervisor Area level
  2. Modify the health_center-create workflow to have the question “In which Supervisor Area will this CHW Belong”?
  3. Set the question type to db:contact since the supervisor_area contact type has “type”: “contact”
  4. See error when uploading the form to the server.

Expected Behavior
I expect to attach CHW Areas to the new level using the health_center-create workflow.

Environment

  • Instance: (eg: alpha.dev.medicmobile.org, etc)
  • Browser: (eg: Firefox, Chrome, incognito mode, etc, which worked, which didn’t)
  • Client platform: (eg: Windows, MacOS, Linux)
  • App: (eg: webapp, admin, sentinel, api, couch2pg, medic-conf, etc)
  • Version: 3.7

Hey @sheila_abby with configurable hierarchy, use db:<contact_type> instead of db:<type>. In your case, db:supervisor_area should work just fine.

Hi @kitsao
I have tried adding db:supervisor_area on the type column of the form.
Getting
pyxform.errors.PyXFormError: Unknown question type ‘db:supervisor_area’.

Hey @sheila_abby I see. It goes back to contact selector, which would be easy to handle in versions 3.10 +. However, since you’re on version 3.7, you’ll have to modify Pyxforms question_type_dictionary.py, in my case located on /usr/local/lib/python2.7/dist-packages/pyxform/question_type_dictionary.py to include the type you’re working with i.e.

QUESTION_TYPE_DICT = \
    {
        ...,
        "db:<contact_type>": {
            "control": {
                "tag": "input"
            },
            "bind": {
                "type": "db:<contact_type>"
            }
        }
    }

Then proceed to convert your forms.

3 Likes

Thank you @kitsao This works!!

2 Likes

I have followed the thread. I comment comming from the resulting json doc for supervisor_areas sampled below…

{
  "_id": "ab794cee-ec20-4b5a-8988-7f45568fe727",
  "_rev": "4-03e1da53e2b2b836cf406ef60442ce7b",
  "parent": {
    "_id": "75b6aff4a8437de809abaca08e13ab18"
  },
  "type": "contact",
  "contact_type": "supervisor_area",
  "contact": {
    "_id": "6f0228e5-768b-4e4c-95cd-82b7d980ac2d",
    "parent": {
      "_id": "ab794cee-ec20-4b5a-8988-7f45568fe727",
      "parent": {
        "_id": "75b6aff4a8437de809abaca08e13ab18"
      }
    }
  },
  "name": "Ruth Kira Supervisor Area",
  "geolocation": "",
  "peer_group_notes": "",
  "reported_date": 1633006698392
}

According to the hierarchy, I believe supervisor_area should be a place with a contact attached to it consider this hierarchy table…

LEVEL PLACE (doc->>‘type’) CONTACT (doc->>‘type’ = ‘person’)
Highest Level (Branch) district_hospital branch_manager
New Level supervisor_area supervisor
CHW Area health_centre chw
Household clinic primary_care_giver
Patient person patient (no doc->>‘contact’)

So to say on couch there should be a new doc->>type which is supervisor_area which is a place. Having this place having doc->>‘type’ contact would mean it is a person hence interfering with queries around all contacts for different places. (contacts for clinic/households, contacts for health_centers/chw area…

Isn’t there a way to introduce a new doc type?

Hey @ocornel good to see you set up configurable hierarchy. You notice that defining the hierarchy involves setting up contact_types in your app/base_settings. While you can set your person contact_type to have multiple parents e.g.

      "id": "person",
      ...,
      "parents": [
        "district_hospital",
        "supervisor_area",
        "health_center",
        "clinic"
      ],
      ...,
      "person": true
    }

you’ll have to check for rightful parents in your queries accordingly, to avoid what you refer to as interference. Alternatively, you can set up your hierarchy such that you have distinct people contact types for each place contact type. For example

   {
      "id": "person",
      ...,
      "parents": [
        "clinic"
      ],
      ...,
      "person": true
   },
   {
      "id": "chw",
      ...,
      "parents": [
        "health_center"
      ],
      ...,
      "person": true
   },
   {
      "id": "supervisor",
      ...,
      "parents": [
        "supervisor_area"
      ],
      ...,
      "person": true
   }

Bottomline, the hierarchy you define in your config and that which you map out in your queries should be in sync.

@ocornel Clarifying your request, are you suggesting that you would prefer to have have two explicit type values { person and place }? Instead of just the one value we currently have contact?