I get a feeling that some implementations want to be able to create new terms on the fly since they are not going to import terms as such, right? And others don't because the terms will be already imported so creating new ones would be a rare case me, therefore it would be no big deal for them to first go to another form and first create the new term before using it. To me, this calls for adding a boolean global property to allow/disallow creating terms on the fly and it will be up to the admin to set it accordingly.
On another note, we(me and Darius) agreed during the scrum chat this morning as suggested by burke's email that we will be adding a service method that fetches term-to-term mappings for a reference term where it is the term b in the mapping i.e 'incoming' mappings to a term from other terms, then these will be listed on the create/edit reference term form as links to the actual terms(term As) that own the mapping. I agree with making name nullable but unique and leaving it blank during migration. Wyclif On Tue, Aug 30, 2011 at 12:37 PM, Burke Mamlin <[email protected]>wrote: > On Tue, Aug 30, 2011 at 11:33 AM, Darius Jazayeri <[email protected]>wrote: > >> 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. >> > > I agree that we should agree. > > >> 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. >> > > Fine with me as long as we have a separate permission for creating > reference terms. > > Ideally, we'd have separate privileges for editing concepts, editing > mappings, and creating refererence terms. Anyone with all three could do > what you say. Someone without the privilege to create reference terms would > _not_ be able to add them on the fly. Someone with the privilege to edit > concepts but not edit mappings would be able to edit other aspects of the > concept, but couldn't change the mappings. > > >> 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.) >> > > I agree that putting the code in as the name is probably not right. It > would be nice to have a separate method for getting the displayable text -- > i.e., that returns "name (code)" most of the time but returns "code" when > the name is missing -- for consistent display throughout the application. > > >> 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.) >> > > Since the name of the mapped term belongs to the reference terminology, > pumping in some default value on the fly doesn't feel right. I'd rather > just leave it blank if it's not supplied -- e.g. SNOMED 62315008 is less > convenient for quickly reading than SNOMED Diarrhea (62315008), but it's not > ambiguous without the name. > > -Burke > > >> >> Quick thoughts? >> >> -Darius >> ------------------------------ >> Click here to >> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >> OpenMRS Developers' mailing list > > > ------------------------------ > Click here to > unsubscribe<[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]
