I think in any of the use cases, the primary means of loading terms will be by some sort of import (actually 2 imports, one for term and one for mappings). There should be 3 options: import only terms; import terms and autocreate concepts for them; import terms and assign/create concepts with IDs in the import source. I don't think the user should create terms on the fly, the same effort could go into preparing the import source with a higher level of accuracy.
The existing concept_map table does not have a name field. I presume that most methods will be designed to use name rather than code. For existing modules which use the map table to locate user-defined concepts, I would duplicate the code field into the name field for records without names. Although it will make for a slightly more complicated changeset, I would make both source and name required, code optional. From: [email protected] [mailto:[email protected]] On Behalf Of Darius Jazayeri Sent: Tuesday, August 30, 2011 11:33 AM To: [email protected] Subject: [OPENMRS-DEV] Creating new reference terms on-the-fly on the edit concept page Hi Andy, Burke, Roger, Ben, etc, Wyclif wants to finish off the work on concept mappings for 1.9. One specific point of discussion was about whether or not you're allowed to create new terms just by entering them as mappings in the edit concept page. Originally Wyclif implemented it such that you could, then we asked him to remove that feature. Then we asked him to put it back. I want to make sure we all clearly agree on an approach. See the screenshot on https://tickets.openmrs.org/browse/TRUNK-412. This shows the page as it stands now. The idea is that if you haven't chosen a Source from the dropdown, then the text box after it will autosuggest possibilities from all terminologies in the DB. Whereas if you choose a source, it searches just terms in that source. My further proposal is that if you have explicitly chosen a terminology, and you type in a term that doesn't exist yet in that terminology, it gets created on the fly (when the page is saved). That will be much easier for the end-user than having to flip to a Manage Terminology page and add the term there, before being able to map to it. And since the user will already have chosen a terminology from the source dropdown, it'll cut down on accidentally creating terms. The further point is that the term table has both a code and a name. I would say that when creating a term on-the-fly in this manner, we should create a term with just code, but leave the name blank. (It seems awkward to add name into the UI.) Also, apparently someone had previously given Wyclif a To Do that both code and name should be required for terms, and when migrating current data with only codes, we should just copy the code into the name column. This seems wrong to me--I'd argue that if we don't know the name we should just leave it null, and not require it. (That said, we can still follow my proposed approach and copy the code the user enters for the term to create on-the-fly into name. Or, for a tougher-to-program and probably more confusing UI, we could make it such that if you type a new code that doesn't match anything in the autosuggest, we display a new Name field.) Quick thoughts? -Darius ________________________________ Click here to unsubscribe<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list _________________________________________ To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [email protected] with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. [mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l]
