Current user data hydration with db-object issue using CHT4

[Gilbert]

We are currently migrating CHT 3.15 forms to CHT 4.9.0.

We have this simple XLS:

It retrieves the current user contact role. It works fine on CHT 3.15.
However, on CHT 4.9.0, the role field is empty.

It appears that data hydration with db-object isn’t functioning correctly for the user.

Do you have any information on this issue?

Thanks.

[jkuester]

We might need to see more of your form config to help debug/recreate this behavior. Specifically, is your user group inside of the inputs group? As noted in the docs inputs/user is the expected place where the form can load data about the user. As far as I can tell, this is the same in both the 3.15.0 code and in 4.9.0.

I tried reproducing this behavior and found I was able to load the user’s data at inputs/user on both 3.x and 4.x code, but I was not able to load user data into a root-level user group either on 3.x or 4.x code.

[Gilbert]

Thank you @jkuester for your response
Yes, the user group is inside the inputs section.
here is the whole inputs group:

[jkuester]

Okay, that is well noted. I can say that the functionality of loading the role data into the inputs/user group should not have changed between 3.x and 4.x (and we have not had other reports of this being broken).

The first question I have after seeing your expanded form config here is that I wonder what you mean when you say that “the role field is empty.” I see in your form config the role field does not have appearance: hidden. Are you expecting to see the role value show up in the text box for that field on the form page? I do not think that functionality has ever been supported (in 3.x or 4.x). Basically, in these web forms, the background data model is maintained separate from the displayed HTML input elements (this is how you can have things like calculate fields that are not tied to any HTML elements). The db-object functionality will populate the data model with the contact data, but it does not push that data up into the displayed input elements (not in 3.x or 4.x). I would consider it a best practice to only use the db-object functionality to load data into hidden fields. However, the data from these hidden fields can then be used in other visible questions/notes throughout the form via calculations and references in other expressions.

type	name	label::en	appearance	relevant	calculation
begin_group	inputs			false()
begin_group	user	NO_LABEL
db:person	contact_id	User’s Contact	db-object hidden
string	role	User’s Role	hidden
end_group	user
end_group
begin_group	first_page	NO_LABEL	field-list
note	original	Original Role: ${role}
string	new	New Role			${role}
end_group	first_page

In this example form, you should the user’s role value displayed in the original note as well as it should be the default value populated in the new text box.

If you still cannot see the user’s role in the note/textbox with the above method, we need to keep looking for the source of troubles…

---

Couple additional questions if you still cannot see the role data via the above method:

1. How are you opening the form? Is it triggered via a task? Are you opening it from a contact’s profile page (on the “People” tab)? Are you opening it from the “Reports” tab?
2. The role data is not getting pulled into the form, but can you check and see what other data (if any) is getting loaded? Is there a value for contact_id? Is any data loaded into the tb_focal_point_info or the parent groups?
3. Can you confirm there is actual a role field at the root level of your user’s contact doc? Also can you check your user’s user-settings document and see if that doc contains a role field (even an empty one). That might be conflicting somehow with the data loaded from the contact doc…

[Gilbert]

Thank you @jkuester

By the role field is empty i meant , we got <role/> in the xml generated by window.CHTCore.debugFormModel().
So, the role is empty because the contact related to the current user is not loaded

Also,we are opening the form from the contact’s profile page.

No other field is loader, as said, the contact is not loaded to allow data hydration

We made this simple form (a new form) to reproduice the issue.
The result below. Same thing, it was not able to load the contact information:

Here is a sample a user contact:

{
  "_id": "xxxxxxxxxxxxxxxxxxxxxx",
  "_rev": "2-xxxxxxxxxxxxxxxxxxxxxx",
  "person_id": "",
  "place_language": "fr",
  "is_active": "true",
  "name_prefix": "STM-",
  "name_regex": "^STM-.{2,}",
  "parent": {
    "_id": "xxxxxxxxxxxxxxxxxxxxxx",
    "parent": {
      "_id": "xxxxxxxxxxxxxxxxxxxxxx"
    }
  },
  "name": "STM-Gestionnaire",
  "language": "${place_language}",
  "select_role": "stock_manager",
  "role": "stock_manager",
  "tb_focal_point_info": {
    "s_site": "Site1",
    "s_ha": "HA1",
    "s_cscom_area": "CSCOM1"
  },
  "concession": "",
  "menage": "",
  "date_of_birth": "2005-08-14",
  "date_of_birth_method": "approx",
  "person_age_in_years": "19",
  "person_age_in_months": "228",
  "cscom_area": "CSCOM1_AREA",
  "ephemeral_dob": {
    "age_years": "19",
    "age_months": "0",
    "dob_method": "approx",
    "ephemeral_months": "8",
    "ephemeral_years": "2005",
    "dob_approx": "2005-08-14T00:00:00.000-00:00",
    "dob_raw": "2005-08-14T00:00:00.000-00:00",
    "dob_iso": "2005-08-14"
  },
  "sex": "male",
  "phone": "",
  "alternate_phone": "",
  "geolocation": "",
  "type": "person",
  "reported_date": 1723642882419,
  "form_version": {
    "time": 1723642782403,
    "sha256": "97f9bc9d4aa223758a4f95ac38ea87b1a8bc13fc7fcbd3028ed0c3dcba1062a8"
  },
  "patient_id": "xxxxx"
}

[jkuester]

Thanks a bunch for the additional data and sample form! I have been able to recreate the issue and was finally able to nail this down as a bug introduced in 4.6.0.

Cannot use db-object-widget to load contact data in non-relevant `inputs` group

My comment out on that issue has more details about the actual issue and a suggested workaround.