Are the icons for this in KC already? And if so, may I grab those and use them with the maintenance documents?

Doug, can you pls attach those icons to this JIRA or provide the SVN link within KC project?

Chitra and William -

They are in KC already. They are all in https://test.kuali.org/svn/kc_project/trunk/src/main/webapp/static/images/

and in there we have the following icons

word.gif
xls.gif
epdf.gif
xml.gif
xsl.gif (although we aren't using it since the mime type is xml)

Sweet, thanks Doug! Going to look at this now to see what all needs to change inside rice code.

Is there a standard way, library or class that handles associating file extensions to mime-type mappings? I looked at jmimemagic, but it looks to be a dead project. Also looked at MimetypesFileTypeMap or even putting it into a simple HashMap, but that requires maintaining the extension list ourselves.

I don't know of a super standard way, but mime-util (http://sourceforge.net/projects/mime-util/) looks a bit more updated than jmimemagic.

For the work I did related to this for KC I just used the mimetype the client provides and that is available through the commons-fileupload. Are you looking for more advanced mime type detection?

See https://fisheye.kuali.org/cru/rice-45
There can be many mime types for a given file extension, at least that is what I am noticing after looking at http://www.iana.org/assignments/media-types/application/index.html but I am sure we can figure out all of them for the 5 unique icons that we have. There are times though during testing that I have noticed that the mime type can be wrong, or it defaults to "application/octet-stream" for which I have used the "clip.gif" as the standard unknown type. I am not so much worried about the mime type detection, more-so about how best we can maintain the association between a mime type to a file extension later on down the road. So far, I have delegated that bit to a utilities Map, but I am wondering if its better off inside of a properties file that we load during startup.

Just so you are aware, Coeus also had a more advanced method of determining mime type but I was told KC did not need to do that and the client sent mime type was sufficient.

For the mime type to extension mapping I put the mappings into a spring map so it was modifiable, but I was wondering about the properties file idea as well.

See revision #16802.

The mimeTypeMapping for AttachmentService includes the directory structure (static/images).

notes.tag's rendering of 'download attachment' link uses this value on top of the regular images path and this adds upto an incorrect filepath.

<html:image property="methodToCall.downloadBOAttachment.attachment[$

]" src="$

$

" title="download attachment" alt="download attachment" style="padding:5px" onclick="excludeSubmitRestriction=true"/>

Have committed the fix for this. Attached are the images of filetype icon display on KC's Test Server showing the problem and same displayed with fix applied locally.

Integrated in rice-1.0.3.2-nightly #51 (See http://ci.rice.kuali.org/job/rice-1.0.3.2-nightly/51/)
KULRICE-4905: Have modified the mimeTypeMapping for Attachment Service

closing since 1.0.3.2 is released.