Hello Team,
we are using OpenMRS 2.3.0 version and while adding drug in manage concept drug it is not searching for drug concept created in concept dictionary with class Drug,with this issue we are not able to save manage concept drug entry,please help us how to resolve this issue in this version.
Thanks, Shravani
See other answers to the same question:
I don’t have any knowledge about this as a known issue. If you ran the SQL version there is a statement which should have regenerated the index:
update global_property set property_value = “” where property = “search.indexVersion”;
if that didn’t run, you should try to reindex (if the data is in the tables as it should be).
I would be interested to know which drugs you are adding to your drug table and the use case too.
Hi akanter,
As sravani my team member has asked you,please find the below details. we are using openmrs 2.3.0 version.for my openmrs related development on my machine i am using windos 10.my another team member for openmrs related development using macos.on both os concept search and drug concept search feature is working fine.but for our testing server we are using linux.and on that concept search and drug concept search feature is not working.some errors appearing. please find the details below.
concept search field is disappeared in linux environment as per below
concept search error in chrome developers tools console showing below error
drug concept search is not working
drug concept search error in chrome developers tools console showing below error
i have already search index built with version 7.you told to use below script
update global_property set property_value = “” where property = “search.indexVersion”;
but issue exits as is.
please help us on this.
Regards,
Can you share a listing of the contents of your openmrs server side scripts folder?
Hi Dkayiwa,
Please find scripts folder attachments link on google drive.
Looks like it might not be a content issue. If the concept.* tables are complete and have the proper collation, then this is a code issue and not a data issue…
Hi Akanter,
Code issue?I did not get that.is that something issue in openmrs 2.3.0 war file what we are using currently.as in windows os and MACOS there is no issue.but in linux environment we are facing above issue.
Regards,
That is what I mean… it is not a CIEL/dictionary problem if the problem is not consistent. However, I would need to hear from @dkayiwa if there is something in the format of the tables/content, etc. which is having a differential effect.
Hi Dkayiwa,
can you please suggest fixes for the above issue.as its urgent for us to go live. Any help appreciated.
Regards,
Hi Dkayiwa,
Please find the below google drive link for openmrs 2.3.0 war file and basic modules to open the openmrs legacy ui.
please help us as we stuck at this point.as our servers are on the linux env. so we can not go live as imp feature concept dictionary is not working. If you need any other files or information,please let me know.
Regards,
Which exact linux distribution are you running?
So, OpenMRS has some files that are served with the incorrect MIME type. This basically means that the response for those resources contains a header called Content-Type with a value that is not a valid Javascript MIME type (in this case text/plain and text/html). While this is less than ideal, for the most part this doesn’t cause issues. If you investigate, f/e demo.openmrs.org and open the network tab of your browser, you’ll see the same files that are raising errors here are served with the same MIME types, but aren’t blocked from executing by your browser (it shows up as a console warning rather than a console error). By default browsers try to be forgiving.
However, if your server sets the header X-Content-Type-Options: nosniff on the response for those resources (which seems to be what’s happening here), the browser uses “strict MIME type checking”, which means that it will only allow a file referenced from a script tag to be executed as a script if the MIME type is one recognised as a Javascript MIME type.
In other words, in the HTML for the Concept Dictionary Maintenance page you will find a tag like this:
<script src="/openmrs/scripts/openmrsmessages.js?v=2.5.9&locale=en_GB" type="text/javascript" ></script>
But when the browser downloads that file, it gets a response something like this:
HTTP/1.1 200
Server: nginx/1.18.0 (Ubuntu)
Date: Thu, 13 Apr 2023 14:46:34 GMT
Content-Type: text/html;charset=UTF-8
Content-Length: 3479
Connection: keep-alive
Last-Modified: Thu, 13 Apr 2023 13:03:21 GMT
Content-Language: en-GB
Strict-Transport-Security: max-age=15768000
X-Content-Type-Options: nosniff
<CONTENT OF THE FILE>
Since the Content-Type here is text/html, which is not a valid Javascript MIME Type the browser blocks the execution of that script (and a couple of others). Unfortunately, those scripts are necessary for the Conception Dictionary search to function, so if they don’t execute (as in this case) you’re stuck looking at a page like that.
By default, nothing in OpenMRS sets the X-Content-Type-Options header. This is done somewhere in the configuration of your application, either, e.g., as something adding to the Tomcat configuration or maybe you’re running a server like Apache or Nginx in front of OpenMRS and it is adding this header.
The issue of scripts being served with the wrong MIME type is tracked in this ticket, but, unfortunately, it hasn’t been resolved yet. Presumably waiting for that ticket to be resolved is going to cause an unacceptable delay in your go-live, so here are some things you can do:
X-Content-Type-Options header.X-Content-Type-Options header only for the files that are showing up as errors in the console logs in your screenshots..js files are served with the MIME type application/javascript
For example, if you are using nginx in front of OpenMRS (I’m more familiar with nginx than Apache; the idea should be the same and the directives should be similar, but the syntax is somewhat different), you might have a configuration like this:
# snip
http {
# snip
server {
listen 443 ssl;
# more configuration
add_header X-Content-Type-Options nosniff; # obey the MIME type
proxy_pass http://openmrs:8080;
}
}
Then you could add, before the proxy_pass rule something like the following configuration to serve those files with an appropriate MIME type:
location = /openmrs/dwr/interface/DWRAlertService.js {
proxy_pass http://openmrs:8080;
proxy_hide_header Content-Type;
add_header Content-Type "application/javascript";
}
location = /openmrs/dwr/interface/DWRConceptService.js {
proxy_pass http://openmrs:8080;
proxy_hide_header Content-Type;
add_header Content-Type "application/javascript";
}
location = /openmrs/scripts/openmrsmessages.js {
proxy_pass http://openmrs:8080;
proxy_hide_header Content-Type;
add_header Content-Type "application/javascript";
}
Simpler fix: use 1.15.0 of the Legacy UI module.
Thank you so much for your quick response.
We have identified it is an issue with Linux server and OS version.issue is fixed we are able to search the concepts without any issues.