Cht-core: Rename configuration fields to be consistent with DHIS2 and make names localizable

[michaelkohn]

Current CHT/DHIS2 integration configuration uses terminology that is not entirely consistent with DHIS2. Excerpts from the documentation are below and the full documentation is here.

A few suggestions:

• In app_settings, rename guid to id
• In app_settings, rename label to translation_key
• Make translation_key translatable

We might also consider changing dhis to dhis2, though who knows if there will ever be a DHIS3.

For reference, here is DHIS2 documentation for sending data sets.

App Settings

CHT Core....

{
  "dhisDataSets": [
    {
      "guid": "VMuFODsyWaO",
      "label": "MoH Monthly Report"
    }
  ],
}

From DHIS2, if you download metadata for Data Sets, it looks like this:

"dataSets": [
    {
      "lastUpdated": "2020-06-01T17:48:22.355",
      "id": "Xa2mJ5ExpMP",
      "created": "2020-06-01T15:58:56.545",
      "name": "AAA-data set1",
      "validCompleteOnly": false,
      "dataElementDecoration": false,
      "publicAccess": "rw------",
....

Contact document

{
  "_id": "my_place",
  "type": "health_center",
  "dhis": {
    "orgUnit": "HJiPOcmziQA",
  }
}

Targets.js

module.export = [
  {
    id: 'births-this-month',
    type: 'count',
    icon: 'icon-infant',
    translation_key: 'targets.births.title',
    subtitle_translation_key: 'targets.this_month.subtitle',
    goal: -1,
    appliesTo: 'contacts',
    appliesToType: ['person'],
    appliesIf: contact => !!contact,
    date: (contact) => contact.contact.date_of_birth,
    dhis: {
      dataElement: 'kB0ZBFisE0e',
    }
  },
]
;

[garethbowen]

Instead of name can we use translation_key? That would make it consistent with other places we have translatable strings.

[michaelkohn]

Sure

[garethbowen]

Although I see the name is exported as well. What is the name used for in the export? Maybe we should have both an export name and a translation key?

[michaelkohn]

DHIS2 does not need the name of the Data Set when you are importing it, so I'm not 100% sure why name would be included in the export.

[garethbowen]

@kennsippell Do you know? Is it just a human readable string to make it easier to scan the file?

[kennsippell]

@garethbowen Where do you see name being exported? The contact.name is used in the admin/src/js/controller/export-dhis.js to create a list of "human readable" orgUnits. But these aren't translatable.

I don't expect to see a name in the exported payload. Here is an example payload.

Do you mean that the label is being exported? When using the "Human Readable" mode for DHIS2 exporting, the dataSet.guid is replaced with the dataSet.label. This label wasn't made to be a translation key in the MVP since 1) admin console doesn't support translations, and 2) it didn't seem necessary for the human readable export format (unsure if anybody even uses this). Seems like a positive change if Admin Console is going to support translations.

I did purposefully just use dhis instead of dhis2 incase there is eventually a dhis3 etc.

[garethbowen]

1) admin console doesn't support translations

Actually it does, for example, the DHIS2 export page is fully translated. We just don't necessarily ship all the admin console translations for all the supported languages out of the box.

Where do you see name being exported?

I saw it in the description of this issue: "From DHIS2, if you download metadata for Data Sets, it looks like this:". It could be that the documentation is wrong?

[kennsippell]

@michaelkohn can confirm, but I think he is exporting a dataset via DHIS2 - in this case the name is the value given as the name of the dataSet via DHIS2.

The CHT only supports the exporting of a dataValueSet which does not reference a name.

[michaelkohn]

Correct. Currently the label field in the CHT is just what shows up in the dropdown of the Admin App. Likewise, the name field in DHIS2 is what shows up in the dropdown in the Data Entry app. So we would be translating the contents of a drop down, NOT the field label. This value does not get sent to DHIS2.

[michaelkohn]

I saw it in the description of this issue: "From DHIS2, if you download metadata for Data Sets, it looks like this:". It could be that the documentation is wrong?

I included the DHIS2 metadata export so you could see what they call the id and name fields (what we are calling guid and label).

[garethbowen]

I've put this in 3.9.0 because changing the configuration schema after release would break backwards compatibility.

[SCdF]

Ready for AT in 6457-fix-dhis-config-schema

[newtewt]

@garethbowen The admin app doesn't seem to respect your selected language on your profile because none of it is translated or maybe I'm missing all the keys for Spanish. Adding a new translation_key for the DHIS dataset though shows the English translation in the drop down even though my users account is set to Spanish.

[newtewt]

I'm also seeing an extra property when I download my app_settings.

    "dhisDataSets": [
        {
            "id": "test1test2test4",
            "translation_key": "data.dhis",
            "$$hashKey": "object:1244"
        }

[newtewt]

Otherwise I think the changes for this are working ok. The export is occuring and using the updated values.

As an aside I am confused how this works in general. I used our births-this-month example and see the target as my offline user but when exporting the value is 0 in the dataValues

[garethbowen]

I'm also seeing an extra property when I download my app_settings.

I think that'll be unrelated to this change. I think what's happening is when rendering the dhisDataSets angular adds the $$hashKey for internal use, then at some point you've saved the config anywhere in the app management app which has saved the property inadvertently. Please raise a separate issue for this.

[garethbowen]

Merged and backported to 3.9.x. I've also merged the medic-docs PR but not the beta docs site one as it's waiting for review.

[michaelkohn]

FWIW.... I'm seeing some inconsistencies in how we name properties and deal with translation keys.

---

In some of our documentation I notice that the property is a normal field name like "title" and the type is of translation key. See tasks.js

---

Sometimes I see that the property is called "translation_key" with a type of translation key. See targets.js

---

Sometimes the property is a normal field name but with no type column. See hierarchy.

Sometimes the property is called "translation_key" with a type of string. See JSON forms

[garethbowen]

Thanks for flagging that! The property names are inconsistent for historical reasons and can't be changed without breaking backwards compatibility so I'm ignoring those for now. I think the type should be "string" because "translation_key" is a Medic convention. The fact that it's a translation key should be explained in the description. @abbyad What do you think?

[michaelkohn]

FWIW... my preference is that it should be something like this:

|Property|Type|Description|Required|
|---|---|---|---|
|name|string|Translation key for the name of the data set as displayed in the UI. e.g. dhis.dataset.name.moh515|Yes|