Datatype Dropdown bug - cannot use one of my common datatypes in a source

[jamlung-ri]

The Datatype field in the Create/Edit Concept form on OCL TermBrowser is not allowing the use of Datatypes that I previously used in the source. As I understand it, the dropdown options for this field in the UI is populated from the Summary API, but the "N/A" value is not appearing since it's not one of the Datatypes in OCL's Datatypes source. This is forcing the user to select a different Datatype value that they don't really want to select.

Proposed solution:

• Datatype field can accept free text inputs, even if they aren't part of the dropdown
• Datatype field's dropdown will show all Datatypes in use in the source, even if they are not one of OCL's "standard" datatypes. In this example, "N/A" should appear in the list as a "Suggested" datatype, and "None" should not if there are no other concepts using the "None" datatype.
• Ensure that "N/A" on the Summary tab shows up appropriately, rather than removing the Slash

Note - This same issue is occurring the the following fields and should take the same approach:

• Concept Class
• Name Type (and probably Description Type)
• Map Type (in Create/Edit Mapping and Quick Add Mapping forms)

Loom video to talk this through more directly: https://www.loom.com/share/80f984f6880e4f41894284fd394e5a48?from_recorder=1&focus_title=1

[paynejd]

@jamlung-ri The approach you described here sounds right for a first chunk of work. Please check Concept Class behavior in the TermBrowser to determine whether the same approach should be implemented there.

This approach effectively unblocks users for the short-term, but there is still a medium-term approach to standardizing datatypes that would be good to include in the requirements that you are developing

Please also report showing "N/A" as "N A" (without the slash) in the summary tab as a bug -- this also happens in the filters panel. The filters panel and the summary tab need to show the original text values, not the "tokenized" versions that Elastic Search uses for indexing

Note: CSV bulk import applies default values to certain empty fields, so as we update the behavior of the lookup fields we may also need to update the CSV bulk import behavior. Please make sure that this is included in requirements that you are compiling

[jamlung-ri]

I can confirm that this is also happening with the following fields: Concept Class, Name Type (and probably Description Type), Map Type (in Create/Edit Mapping and Quick Add Mapping forms)

[snyaggarwal]

Datatype field can accept free text inputs, even if they aren't part of the dropdown

@jamlung-ri in OpenMRS validation schema datatypes needs to be from lookup values, custom values are not allowed. I am assuming this custom input is for non-OpenMRS schema repos, right?

[jamlung-ri]

@snyaggarwal We are working through the long term approach for this, but for now, let's relax the Datatype and Concept Class fields in the Create/Edit concept forms. Meaning, any value can be inputted into the field, even if it's not part of OCL's official sources. Here are the changes that @bmamlin and I discussed:

• Concept form will allow you to put in custom values like "N/A" instead of "None"
• Concept form will put all values from the Summary API in the "Suggested" section of the dropdown. For example, if PIH used the "N/A" value in the past, it should be selectable in the Datatype dropdown.