[KULRICE-4905] Display appropriate icon based on attachment type in Maintenance Documents Created: 26/Jan/11  Updated: 28/Sep/11  Resolved: 13/Jun/11

Status: Closed
Project: Kuali Rice Development
Component/s: Development
Affects Version/s: None
Fix Version/s: 1.0.3.2, 2.0
Security Level: Public (Public: Anyone can view)

Type: Task Priority: Major
Reporter: Chitra Chandran Assignee: William Balderamos (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 2 days, 4 hours
Original Estimate: Not Specified

Attachments: JPEG File attachmentsAfter.JPG     JPEG File attachmentsBefore.JPG    
Issue Links:
Cloners
cloned to KULRICE-5696 Display appropriate icon based on att... Closed
Relate
Similar issues:
KULRICE-5696Display appropriate icon based on attachment type for Persistable Attachments in Maintenance Documents
KULRICE-5106Maintenance Document does not display attached file
KULRICE-5363Inquiry - Support for displaying bo attachments and downloading
KULRICE-6890make the note/attachment framework available for maintenance documents
KULRICE-5809ComponentMaintenanceDocument document type missing
KULRICE-1782Build Group Type
KULRICE-5130Sample Maintenance Document for testing attachments
KULRICE-7051The "Queue Document" button on the Document Operation screen may not be forwarding back to the appropriate application properly
KULRICE-5118Old attachments in Maintenance Documents not showing except on a document reload
KULRICE-2915When clicking on the lookup icon for "Parent Document Type" on the Document Type lookup, we need to change the label in the header of the page to read "Parent Document Type"
Rice Module:
KNS
Application Requirement:
KC
KAI Review Status: Not Required
KTI Review Status: Not Required

 Description   

While maintaining the attachment associated with a Maintainable BO, we need appropriate file icons to be displayed based on the MIME type.



 Comments   
Comment by William Balderamos (Inactive) [ 14/Apr/11 ]

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

Comment by Chitra Chandran [ 14/Apr/11 ]

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

Comment by Douglas Pace [ 14/Apr/11 ]

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)

Comment by William Balderamos (Inactive) [ 14/Apr/11 ]

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

Comment by William Balderamos (Inactive) [ 18/Apr/11 ]

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.

Comment by Kristina Taylor (Inactive) [ 18/Apr/11 ]

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.

Comment by Douglas Pace [ 18/Apr/11 ]

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?

Comment by William Balderamos (Inactive) [ 18/Apr/11 ]

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.

Comment by Douglas Pace [ 18/Apr/11 ]

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.

Comment by William Balderamos (Inactive) [ 20/Apr/11 ]

See revision #16802.

Comment by Chitra Chandran [ 13/Jun/11 ]

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[$

{status.index}

]" src="$

{ConfigProperties.kr.externalizable.images.url}

$

{note.attachment.attachmentIconPathByMimeType}

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

Comment by Chitra Chandran [ 13/Jun/11 ]

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.

Comment by Rice-CI User (Inactive) [ 14/Jun/11 ]

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

Comment by Jessica Coltrin (Inactive) [ 09/Sep/11 ]

closing since 1.0.3.2 is released.

Generated at Fri Jun 05 07:52:01 CDT 2020 using JIRA 6.1.5#6160-sha1:a61a0fc278117a0da0ec9b89167b8f29b6afdab2.