Filename stored when processing an webpage

Project:RUcore Workflow Management System (WMS)
Version:7.6
Component:File Upload Module
Category:bug report
Priority:normal
Assigned:yuyang
Status:postponed
Description

The filename that is stored in the foxml ALT_IDS attribute when generating a PDF from a web page is the webpages URL. This causes an access issue because the filename is missing the .pdf extension rendering the file useless when downloaded.

Comments

#1

Version:7-x» 7.6

#2

ALT_IDS stores the original file name (normal file upload). This bug entry is about url upload. In this case, what would be the entry for ALT_IDS? Should it be some artificial pdf file name? Just let me know. -YY

#3

I would suggest not setting an ALT_ID. Then the file name will be generated from the Fedora PID, datastreams ID and the datastreams configured file extension.

Something like this will be automatically generated: rutgers-lib_1234-pdf-1.pdf

#4

Chad, since you have to do something to generate file name anyway, even if ALT_IDS is empty (am I correct?), why don't you just to that when you see an url in ALT_IDS. This way at least we have a record of original url on file. -YY

#5

I would rather not test the validity of information stored in the ALT_IDS attribute. That is a slippery slope. I think if something is there I should be able to trust it is accurate.

Besides that isn't the location, URL, stored in the metadata somewhere? I would expect something in the metadata that said this "webpage" was captured from this URL on this day and time. Maybe the metadata is lacking on that area.

The original issue wasn't with the filename, but the extension that was placed in there was wrong; i.e. .html and not .pdf.

#6

ALT_IDS is the place to catch the original file name. There is no other mandate to catalog this. The right place is probably in technical MD, but they are not doing it. I will just put "webpage" in this field. -YY

#7

Well, to be safe, maybe I should ask Jane and Rhonda. Stay tuned. -YY

#8

Status:active» postponed

This is an issue discussed in sw_arch group and I am waiting for the decision on how to handle the case. I suggest we move it to 7.7. -YY

Back to top