1) Why DICOM images are handled generically
Only two ad-hoc viewers have been implemented so far: one for images and one for PDF files. Any other types of files will be handled generically. The generic handling consists in simply storing the file and providing the ability to download it again, which is what you have observed.
You will rightfully tell me that DICOM images are images. That’s true, but their MIME type is not specifically filtered by Attachments, see here why this happens. The very first thing that I think you should try doing on your fork of the module is to expand this method so that Attachments recognizes DICOM files as part of the so-called ‘image content family’.
Note that for this to work you will also have to add the DICOM MIME type to the global map (here):
I don’t know if a DICOM image can just be viewed as any usual image (JPEG, PNG, … etc), I doubt so, and therefore I think that the above will not work. But please try it out and let me know your findings. If it doesn’t work it will mean that the DICOM MIME type case will have to be handled entirely specifically, which is what I suspect. But let’s try the above first and let me know how it goes.
2) Why other complex obs are not being seen through Attachments UI
For Attachments to incorporate in its UI complex obs that were saved elsewhere, you will have to tell it to do so through the following GP: attachments.conceptComplexUuidList (see here):
Adding the UUID of the concept complex that you wish being handled should work. Attachments should then start listing those files along the others (assuming they’re bound to a visit, but this can also be toggled off). I seem to remember that there might be a bug there and that this might not work as expected, I would be curious to hear your findings about it.