Hi,
What is the objective of the data section of the form. I’ve looked at the various forms on the default app and see the group called data and its not clear to me what that section does. Any insights?
Thank you.
Erick
Hi @ewafula,
I can see the appearance column for the group named data is set to hidden and the calculation column has some expressions to capture values from the form to these fields which are of type calculate.
Hi @Jennifer_Quesada and @jkuester , any thoughts on what this section is used for?
To my knowledge, there is no special functional role for the data group (I do not believe it triggers any type of special logic in the CHT). So, I think the usefulness of this group would depend on the needs of a specific project.
Looking specifically at how the data group is implemented in some of the default forms, I see a few key things:
- The group has
instance::tag = hidden. - The calculated fields in the group do not seem to be used in other expressions within the form
This means that the fields are not related to the form functionality and also they do not get displayed to the user (when viewing the submitted report on the Reports tab). Instead, I would guess that the primary purpose of these fields is to provide a convenient de-normalization of a subset of the report data when it is ingested into a Postgres DB by couch2pg.
1 Like
Thank you @jkuester and @niraj for your feedback. This is very insightful and I’ll be following closely to see how this looks like in Postgres DB.
I’ve an additional question on how to render reports in user readable format especially when your data is coded. For example for variables where the response are yes_no coded as Yes = 1 and No = 0. I noticed that the report shows the coded values. Is there a way or something I need to do so that the report can render the coded values in a human readable format?
See the screenshot below
So the Question “Is this a Routine CHW/VHT Visit?”
the value should be rendered as “Yes” instead of the coded value of 1.
Hope my question is understandable. Thank you.
Unfortunately, there is no way (that I know of) to configure translations for the specific values recorded on a report. Many forms I have seen do set the names for the yes_no choice list to be yes and no. These names are are stored to the report (and so would be displayed on the Reports page), but that is not super helpful when it comes to wanting multiple translations or for displaying a phrase instead of a single word.
Honestly, the Reports page has not gotten a lot of love recently. Many projects do not make much use of it (or disable it entirely). We could absolutely explore some possible enhancements to this page (such as translations for select choices) to make it more friendly for readers.
It would be super helpful to have a better understanding of your intended use cases for the Reports page! What types of users would be using it? What kind of reports would they be looking at? Why?
Thank you @jkuester , for now we will let that be, but in my mind I thought since they are listed on the participant profile and when clicked they do not render so well similar to the input form.
This was supposed to help the chw to be able to see what they have entered at a glance while hiding the coding the select choices.
Some addition question on how to hide some fields form being displayed in the report. The hidden_fields attribute in the formname_properties.json should help me do this but for some reason this is not happening. What is the right format for listing the fields to be hidden?
Erick
Hmm, I just double-checked and I have no problems using the hidden_fields attribute in the form properties to hide fields on the Report page. (Silly question, but I have done this before, so seems worth checking: you are using formname.properties.json and not formname_properties.json right?)
As you may have noticed in the default forms we tend to use the instance::tag = hidden in the actual xmlx itself more than the hidden_fields in the properties. Both should work (and can even be used together), but the instance::tag provides more fine-grained control of which fields get hidden.
I’m using formname.properties.json, I suspect the problem could be way I’m specifying the field/variable names to be hidden. Is there a specific format that I should use? For example if my xlsx has a field called “sbp1”, is this the same that I should use in hidden section?
For example if my xlsx has a field called “sbp1”, is this the same that I should use in hidden section?
Yes, I would expect your properties to look something like this:
{
"title": [
{
"locale": "en",
"content": "Test Form"
}
],
"hidden_fields": [ "sbp1" ]
}
Please note this section from the CHT docs:
This is only applied to future reports and will not change how existing reports are displayed.
The list of which fields should be hidden is stored in the individual reports, not in the form definition. So, any changes you make to the list by modifying either the form XLSX/XML or formname.properties.json file does not apply to the reports already submitted.
1 Like
Hello everyone,
We’ve successfully hidden individual fields or entire groups by incorporating them into the ‘hidden_fields’ section within the properties file. However, we’ve encountered a challenge when attempting to hide a specific field within a group in the xlsx file.
Has anyone figured out a solution for this? We attempted to use syntax like ‘outside_group.inside_group.name’ in the ‘hidden_fields’ section, but unfortunately, it didn’t yield the desired results. Any insights or suggestions would be greatly appreciated!
