I am trying to run Reports on OpenMRS via Reporting module. The report result set returns data when run directly from data-set-definition or report preview, however, when report is queued it just keep running in queue forever. The data set is not huge and query has been tested. However, an exception is seen in openmrs.log which can be seen here (https://pastebin.com/NGTBYK3r).
The versions of openmrs components are below
OpenMRS : 1.11.5
Serialization Xstream : 0.2.12
Reporting : 1.13.0
Rest Web Services OMOD : 2.17.1cd94b
Calculation : 1.2
Surprisingly this issue doesnot occur on Linux server but our Windows server is throwing this issue. I also tried installing reporting rest module but that didnot help.
I am uanble to figure out what could be the possible cause of issue because I am using admin account to run report, I also explicitly gave all ‘Get.*’, and other reporting privileges to a role and assigned it to admin user.
I ran into a similar problem on a client’s server recently. The issue was the scheduler password Global Property (Advanced Setting). I see in the log it’s complaining “Basic authentication required”. To check the scheduler username/password, go to Administration --> Advanced Settings. Look for the following settings and ensure they have values that work (the account specified is able to run reports)…
scheduler.username
scheduler.password
Thanks @arbaughj , this gives the clue but changing user and password didnot solve my problem.
I have tried all following steps but problem still persists:
Change properties`s user and pwd to admin account and try running report
Stop and start tomcat and try running report
Clean openmrs work and temp dir and run report again
Create a new account and give explicitly all report permissions and system developer role and and try running report
Gone through openmrs runtime properties but nothing found that could have overridden the settings in global_setting table
Gone through all relevent report tables but no report definition contains the values for user account that could have overridden the properties in global_setting table
The openmrs deployment was done from an existing database and the values for scheduler were admin:test i.e. default openmrs credentials (these had been changed from change password section after deployment on production server and may have not updated in scheduler settings).
Is there any possibilty that this has been hardcoded anywhere in code?
Is there a way to override/bypass the basic authentication in scheduler?
Is there a way to run report without passing it to scheduler or reporting task? We just need to download a CSV on the fly.
We have been using reporting module since long and never faced this issue. Would it help to downgrade the module?
@maimoonak did this happen only after upgrading the module? In other words, if you temporarily reverted to the older version that you were using, does the problem disappear?
No this happened when we installed openmrs from an existing database copied from another server. And admin password was changed. Initially we were using reporting-1.12.x and after facing this issue we upgraded to reporting-1.13.0. I also tried reporting-0.9.x which we are using for another project but that caused some checksum issues with liquibase.
FYI - @arbaughj and @maimoonak, the reporting module no longer uses the scheduler.username and scheduler.password properties, but rather runs all scheduled tasks as the daemon user. As described, the daemon user has all privileges - it is essentially a root user. So I would not expect to see any privilege issues causing problems here (though I do agree that this is what the log shows).
Could you change the log level to debug on org.openmrs.aop.AuthorizationAdvice and see if this provides any more information that could be helpful in the log?
