Compiled and installed https://github.com/openmrs/openmrs-module-attachments into The Reference application 2.7.0, it however didn’t load right the attachments page, see: https://snag.gy/G4Ceo2.jpg
Investigate and saw no server logs when loading this page where’s its administration only one link was broken
@mksd, have you or any of the core devs on this experienced this before
It looks like an Angular error, could you keep an eye on the Chrome console when refreshing that page?
Also it would be interesting to build a release point (rather than the tip of master), say tag 1.3, and install that OMOD to see if you also experience the issue. The module was refactored/renamed in the meantime, so don’t be surprised when building a release point to obtain a a Visit Documents module and not yet the newer Attachments module.
There hasn’t been much changes on the UI side recently, but still, at the moment this module is under development ahead of the 2.0.0 release. Just to say that it would be worth checking whether some regression was introduced since the most recent release point (version 1.3).
Ah but wait, the default setting is that you would need an active visit to be able to do anything, is it the case of the patient in your screenshot?
this was the issue, wouldn’t be better letting the user know that the page expects an active visit. I would also think it wise to attach the attachment rather to an encounter within a visit to be specific.
thanks
did you guys see: https://github.com/AbhijitParate/DrawingAndDocument and try it out, seems cool on first look.
CC: @abhijitpparate
Could you create an ATT ticket for this?
No I didn’t know of that DrawingAndDocument module. Definitely an interesting use case, great work @abhijitpparate! However after a quick glance I would see some convergence that could happen with a module like Attachments. It seems that those drawings could just be uploaded via the Attachments API, leaving the module focusing on this drawing functionality only (rather than re-doing the whole file management yet again).
Also @abhijitpparate I see that you have committed output files to your repo, you should play around with your .gitignore file to clear them out of the code base.
@k.joseph, Attachments API is meant to be a central point to manage complex obs, regardless of where/how they had been created in the first place. It can handle virtually any content through generic controllers. However Attachments UI is currently limited to a certain number of use cases and is solely focused on integrating the Ref App. If you have some manpower, you could jump in, Attachments is currently the subject of a GSoC project to move it towards its 2.0.0 release. See ‘Attachments Module Enhancements’.
Thanks @k.joseph however I’m not sure this makes sense. There can’t be an encounter if there is no (active) visit anyway. That’s my assumption anyway: there can’t be visitless encounters.
I guess you wanted to ensure that, if the configuration is based on the active visit (which is the default, but can be switched off), when there is no active visit the UI should clearly state that this is why nothing can be done on the main page. Am I correct?
correct. I want a failure that is known to the user if there was no active visit while loading from patient dashboard endpoints.
Since any visit can have more than one attachment, attachments are better hooked to encounters rather than just a visit,
explanation: a patiet comes and goes through the registration desk and then to a health care worker(HCW) for consultation and medication who reviews former medical forms from another facility and wishes to stick them onto his new encounter with the current patient, thus scans/photos them and attaches former facility documents and proceeds the patient after medication to the lab for an X-ray which is also to be attached onto the same patient visit. In this case, the patient has done one visit with 2 encounters, at each encounter both with the HCW and lab technician, the System needs to support attachment uploading.
Let me know if this explains enough why i think attachments are better mapped to encounters rather than visits!
Currently the module can be configured in three ways:
By ad-hoc I mean that the module configures which encounter type will be used for the encounters to hook attachments to.
I think that you are suggesting that you want to use the latter case by specifying the encounter type to be something else than the default, see here.
