Cht-core: Default Add Place and Add Person forms

[estellecomment]

From discussion on design issue #2719

Our default forms don't make sense with the updates on the People tab, so they need to be updated.

Design spec:
https://docs.google.com/document/d/1UwSe8H3xykvOUwu65KxJYgBTxv40Y_9b3CPgRbcXOH0/edit?ts=57f7fabd#bookmark=id.kaz9vme2zuol

Edit : snapshot of the content of link above :

Our default config is for SMS projects, hence the following default forms are with SMS projects in mind:

Default Add Place form:

• Allow the user to select if the place should be named after the primary contact (can be pre-selected / checked by default in config)
• Display the parent place
• Not allow the user to change the parent place during the creation process (editable later from the “edit” button).
• Not allow the user to change place type -- ever. Hide other place types in the form.
• Primary Contact: add new or select from existing contacts
• External ID (leaving it by default to prompt PM to ask the design question of whether it’s needed for that project).
• GPS (let’s capture by default which will also serve useful in our demos)
• Notes
  We can have custom place type forms, but the main difference will exist for households only. Since SMS projects won’t be creating households, this default form should work for all place types.

Default Add Person:

• Phone number
• Alternate phone number
• Role (drop-down list: CHW, CHW Supervisor, Nurse, Facility Manager, Other (fill in))
• Display the parent place
• Not allow the user to change the parent place during the creation process (editable later)
• External ID
• Notes

[abbyad]

We should create this default form as an XLSForm, which would make it easy for tech leads to modify them for their projects. This issue can be picked up by a tech lead, @sglangevin or myself.

[abbyad]

Assigned to @ngamita to be worked on by tech leads with support of @sglangevin and myself.

[diannakane]

the default add person form shouldn’t require a ph#. this is particularly relevant when adding a person who is a child.

[diannakane]

Can we have a checkbox in the form that says, “name this place after the primary contact”?

Ideally, it can be checked by default and unchecked by the user if relevant.

[abbyad]

Yes, we can do that. Good idea.

[garethbowen]

Alternatively we could have a "name" field which prepopulates to "'s area" where name is what the user entered for the contact name.

[abbyad]

That's another option, although the UX is a little trickier for an XForm. We can put it on a different page to mitigate, but not eliminate, some of the issues. For instance, re-editing the person field overrides a manually entered place name.

I think we'll have to create a couple of options and test it.

[sglangevin]

I created a version of a place creation form (I think Area) that has a field that can be pre-populated to use the person's name for the place name. See the health_center form in the diy folder in medic-projects.

[diannakane]

@sglangevin can it be made possessive, e.g. "Dianna's area" instead of "Dianna Area." I know LG preferred to leave the 's off, but it would be nice to have on our default forms.

[abbyad]

@alxndrsn the ID of the parent is passed to the create person form -- is it possible to find its name and type? Is that info passed at all to the inputs? If not I'll spin off a new issue.

[alxndrsn]

@marc From a quick look it seems like the parent comes directly from the contact being edited. Which suggests that whatever data is embedded directly in the person doc will be available. If contact.parent is just an ID, this is all that's available; if contact.parent.name etc. all exist then they should be available.

[sglangevin]

@diannakane we can do it any way that is needed. The naming convention is set by the form.

[abbyad]

Moving to Acceptance Testing, but @alxndrsn feel free to do code review. After acceptance testing we can decide whether to pull these forms in as the true built-in defaults, or to use them as a base for projects.

[abbyad]

If you create a place without a contact a contact is still created but with a blank name

Step 1: Skip selecting a contact

Step 2: See blank contact

[abbyad]

Ready for Acceptance Testing again.

[estellecomment]

These forms are in medic-projects, which means you need to upload them to see them in your instance. Do they get packed into the instance by default @abbyad ?

[abbyad]

No they don't automatically get uploaded by default. Is it easy to include them with any fresh instance?

[ngaruko]

I guess we need to clarify what is the 'default' configuration vs 'standard' (if there is) and have an instance with such configurations for testing purpose. I understand from @abbyad and @sglangevin that this work in progress.

[estellecomment]

@abbyad Don't know! Opening a separate ticket for this.

[abbyad]

Ya, it can be a little confusing! The decision to use the SMS workflow for CHWs as the default config was perhaps decided after the issue was created. Also, it is relatively new that we are referring to our default configuration as our "standard app/deployment".