Why not just use the "Manage Reference Terms" privilege to deal with this? If the user doesn't have that when creating a concept, they can only choose from existing. If they do have it, they can either choose from existing or map from there.
The only downside to using a privilege to do it is that System Developers will always have it, theres no way to limit privileges on root users. Ben On Wed, Aug 31, 2011 at 2:00 AM, Burke Mamlin <[email protected]> wrote: > -1 for YARGP (yet another random global property) > +1 for managing through privileges. If we want to toggle the ability to > create reference term while mapping, then make a Can Create Reference Term > While Mapping privilege and let the admin decide who -- if anyone -- they > want to grant it to. Personally, I would trust anyone who can create > rerference term entries to control him/herself when editing mappings if we > decided not to create them from the concept editing form... so I could live > without the extra privilege and manage it socially. > > In either case, it's going to be important to distinguish between creating a > new reference term vs. selecting an existing one -- i.e., instead of just > making the field behave as a free text field that automatically creates a > reference term if you happen to make a type in the code, there should be an > explicit "create new term" option (in the choice list or via small link) > that prompts for source/name/code (in a popup) and then automatically adds > it as a mapping once created. > > -Burke > On Tue, Aug 30, 2011 at 4:16 PM, Darius Jazayeri <[email protected]> > wrote: >> >> My assumption about how many implementation dictionaries are managed >> (though I haven't verified) is that you would almost never map a concept to >> a term, but occasionally someone will tell you that the ICD code for malaria >> is xyz, and you'll add that one mapping to a concept. >> >> So I agree that enabling this workflow via a global property makes sense. >> >> -Darius (by phone) >> >> On Aug 30, 2011 3:01 PM, "Wyclif Luyima" <[email protected]> wrote: >> >> 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 3... >> >> ________________________________ >> Click here to unsubscribe from OpenMRS Developers' mailing list >> >> ________________________________ >> Click here to unsubscribe from OpenMRS Developers' mailing list > > ________________________________ > Click here to unsubscribe 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]
