Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Full size images in encounter queue #1

Open
zhalloran opened this issue Jul 31, 2015 · 5 comments
Open

Full size images in encounter queue #1

zhalloran opened this issue Jul 31, 2015 · 5 comments
Labels

Comments

@zhalloran
Copy link

've just started working with sana.openmrs, and we're running into an issue where images are being displayed at full size in the encounter queue. I've been tracing the call on line 505 of /omod/src/main/webapp/queue/v1/queue.jsp [<img src="${pageContext.request.contextPath }/moduleServlet/sana/complexObsServlet?obsId=${obs.obsId }&view=VIEW_THUMBNAIL"/>]. Any help would be greatly appreciated.

Thanks!

@ewinkler
Copy link
Contributor

My immediate thought is that the thumbnail image of the complex data isn't getting rendered. Which handler are you using in the Concept you defined for the image data? To get the thumbnail, you would need to use the ThumbnailingImageHandler included in the Sana encounter queue module. See the example screenshot from our demo server below. Let me know if that fixes the issue. If not, we can dig into the issue further.

image

@zhalloran
Copy link
Author

@ewinkler This was very helpful. I'm now running into an issue where the existing encounter images are showing up as either broken or full sized. For the broken images where getting a 500 with a Null Pointer Exception. When I look in our server log, I see this:

ERROR - ThumbnailingImageHandler.getThumbImage(250) |2015-07-31 17:31:16,058| getThumbImage(File::/usr/share/tomcat6/.OpenMRS/complex_obs/thumbnails/191.jpg) -> IOException::Can't read input file!

Which makes sense because the file doesn't exists.

My guess would be that there's a permissions issue preventing the thumbnails from being written, except there are no errors to that effect in the log, and it wouldn't explain why the same two files would be returned at full size. If this behavior rings any bells, please let me know. Thanks!

@ewinkler ewinkler added the bug label Aug 2, 2015
@ewinkler
Copy link
Contributor

ewinkler commented Aug 2, 2015

I don' think it is a permission issu. After reviewing the source code, what I think is happening is that the thumbnail generation is being skipped for existing observations when the handler for the Concept was changed since the thumbnail generation gets triggered during a save call on an observation. I am going to go ahead and mark this as a bug for now since the ThumbnailingImageHandler really needs to be able to handle cases where a Concept's handler gets changed-i.e. create the thumbnail on an observation fetch if it doesn't exist. While that is being looked at further, what you can try doing is accessing the observations where the problem is occurring through the OpenMRS web interface and navigating to:

  1. Administration
  2. Manage Observations
  3. Locate the existing observations using the search inputs-i.e. "person and concept" might be easiest.
  4. Select the "Value" for the observation which will take you to the default OpenMRS edit observation page.
  5. Add an edit reason and save.

That should trigger the thumbnail generation. It is a bit of a hacked workaround for the moment but I will try to get a fix for this into the module as soon as I can.

@zhalloran
Copy link
Author

I'd come to the same conclusion regarding the handler after reviewing the code. I'd be happy to submit a pull request when I modify the handler if that's something you'd be interested in. 

@ewinkler
Copy link
Contributor

ewinkler commented Aug 3, 2015

We would definitely be interested to have you submit a pull request with any changes. Contributions back into the code base are always much appreciated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants