FSN Based Concept Search is not returning results for non-English locales (when FSN is not present for that locale)

Software Platform
, ,
1

Summary: In OpenMRS AdminUI, if one logins with a non-English locale (like French), which is a different locale from the default locale, then a search of concepts in the dictionary doesn’t return any results if the specified concept string is not found in that locale. Earlier in OpenMRS (2.1.x), one was able to see results from English locale, if the specified search string was not present in the user’s locale. It seems the Concept Search API behaviour might have changed across 2.1.x to 2.5.x. This is causing some concept searches to break in non-English locale now.

Details:

  1. When we login in Openmrs AdminUI and set its locale to be french for example (anything other than English which has a fully specified name of the concept specified) then we are unable to see that concept. In older version of OpenMRS it used to show the concept and even the concept search api used gives a result array with that concept. This means that if french doesn’t have any concept with FSN of the one which we are searching it used to give response from default locale which is English in our case, but now it returns and empty results array.

In our case we had a concept set with fully specified name as Nutritional Values in English. While in french it doesn’t have any FSN, if we search it in dictionary with logged in user locale as English it shows the concept but if logged in user is french it doesn’t.

/openmrs/ws/rest/v1/concept?s=byFullySpecifiedName&locale=fr&name=Nutritional+Values&v=bahmni

this is the api which is hit to search for the concept here ,

  1. We also have another question. Is the locale=fr param being used or validated? Because on removing the param and keeping the param the result didn’t change. Is it the param through which the openmrs backend checks for the locale or is it from the JSESSIONID from where it fetched the locale and search whether the concept is there or not?

Since the concept search API is now returning no results, if it doesn’t find the FSN in the current locale, it seems clients will need to make a second call with default locale to search. Earlier, the concept search API used to do this automatically. This is causing some screens in Bahmni to not work in non-English locales, if the specific locale doesn’t have translation for a concept.

Any guidance from OpenMRS team will be very helpful.

cc: @angshuonline @gsluthra

2

image
image1850×1053 72.7 KB

The above image is captured with french locale it gave no concept while earlier it used to search it with default if french dont have one and return that one…

3

image
image1850×1053 73.5 KB

This one is captured with locale set as English and did gave us a response .

4

I have just installed a fresh instance of OpenMRS Core 2.1.0 but failed to reproduce the old behavior. Do you have any online instance of OpenMRS where i can reproduce the old behaviour (of being able to find concepts in other locales)?

1 Like
6

I was not able to reproduce the reportedly old behaviour, even on the demo version of bahmni which runs openmrs platform 2.1.7: OpenMRS - Home

7

Yah @dkayiwa just checked it is because the previous version of bahmni was not setting the locale correctly due to which openmrs locale used to be english only and returns correct value.

8

Sounds like this topic was discussed on last week’s PAT call - @anubhavbansal or @gsluthra or @dkayiwa what was the takeaway? Were we able to reproduce and i.d. the bug? Because I imagine this would impact all OMRS distros, not Bahmni-specific-only.

9

It is not a regression. That is how the OpenMRS core platform has always behaved for all versions. If we want to change this behaviour, it would be a new feature request.

1 Like
10

Linking to the Slack thread where there was additional discussion on this: Slack