-
-
Notifications
You must be signed in to change notification settings - Fork 204
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rename configuration fields to be consistent with DHIS2 and make names localizable #6457
Comments
Instead of |
Sure |
Although I see the name is exported as well. What is the |
DHIS2 does not need the |
@kennsippell Do you know? Is it just a human readable string to make it easier to scan the file? |
@garethbowen Where do you see I don't expect to see a name in the exported payload. Here is an example payload. Do you mean that the I did purposefully just use |
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.
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? |
@michaelkohn can confirm, but I think he is exporting a dataset via DHIS2 - in this case the The CHT only supports the exporting of a dataValueSet which does not reference a |
Correct. Currently the |
I included the DHIS2 metadata export so you could see what they call the |
I've put this in 3.9.0 because changing the configuration schema after release would break backwards compatibility. |
Ready for AT in |
@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. |
I'm also seeing an extra property when I download my app_settings.
|
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 |
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. |
Merged and backported to |
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
|
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? |
FWIW... my preference is that it should be something like this:
|
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:
app_settings
, renameguid
toid
app_settings
, renamelabel
totranslation_key
translation_key
translatableWe might also consider changing
dhis
todhis2
, though who knows if there will ever be a DHIS3.For reference, here is DHIS2 documentation for sending data sets.
App Settings
CHT Core....
From DHIS2, if you download metadata for Data Sets, it looks like this:
Contact document
Targets.js
The text was updated successfully, but these errors were encountered: