Upload documents in Vitro|VIVO

[litvinovg]

Github Issue
Goes with PR in VIVO
Goes with PR in Vitro-languages

What does this pull request do?

Introduces upload files associated with individuals in Vitro|VIVO

What's new?

New File Upload Controller to upload and delete files on file storage
New vitro-public:pulicFilename data property to save uploaded file name.
New vitro-public:storedFile object property. As an example to allow users to attach file to specific individuals.
List view for this property (can be used for any other custom properties with Range class vitro-public:File).

New config options:
Max allowed file size in bytes
fileUpload.maxFileSize = 30000000
Allowed upload mime types
fileUpload.allowedMIMETypes = image/png, application/pdf
Adds new dependency on Apache Tika to detect file MIME type.

How should this be tested?

Set/uncomment config properties (mime tyes and max file size).
Set domain range for vitro-public:storedFile property to some individual class, for example http://purl.org/ontology/bibo/Book. Create individual of this class.
Got individual page, find storedFile + icon. Try adding some files to it. After uploading you should see files in list and have option to download files by clicking. Also try removing files by clicking on basket.

Example:
This change requires documentation updates:

• Where to set max file size
• Where to set allowed mime types
• How to create custom object property for file upload and set list view for it.

Interested parties

@VIVO-project/vivo-committers

[gneissone]

I think this is a useful PR, though https://wiki.lyrasis.org/display/VIVO/Call+for+Interest%3A+Integrating+DSpace+with+VIVO may complicate the use case if it moves forward. An argument could be made that this is useful for simple use cases, such as attaching CVs to profiles or a PDF copy of a preprint, though people will still want to use DSpace for the more advanced features, such as download tracking or versioning.

[chenejac]

Works as described. I believe this might be a really valuable feature. However, I have one concern related to the organization of the code. From my point of view FileUploadController should be much shorter, while part of its code should be moved to a Helper. It might be UploadedFileHelper, or the another option might be to create one additional Helper in between, similarly as for ImageUploadControler -> ImageUploadHelper -> UploadedFileHelper.

[chenejac]

@gneissone wrote:

I think this is a useful PR, though https://wiki.lyrasis.org/display/VIVO/Call+for+Interest%3A+Integrating+DSpace+with+VIVO may complicate the use case if it moves forward. An argument could be made that this is useful for simple use cases, such as attaching CVs to profiles or a PDF copy of a preprint, though people will still want to use DSpace for the more advanced features, such as download tracking or versioning.

I believe VIVO should offer customization/configuration of usage of numerous assets management (graph database, DSpace, Fedora), similarly as numerous graph databases (jena, TDB, SDB, fuseki), and search engines (Solr, ElasticSearch). Therefore, I agree that this contribution might be very useful for simple use cases, and it might cover needs of significant number of VIVO users. For those with higher expectations and assets management features lists, integration of VIVO with DSpace might be an option.

[chenejac]

MIME Types not localized (i18n). Do we need both supportedTypes and supportedMIMETypes?

[litvinovg]

supportedTypes is a list of allowed file extensions for user's convenience.
supportedMIMETypes are less easier to read ( image/png, application/pdf )but more strict definition of file types allowed by configuration.
I decided to provide both for regular and experienced users.
I don't think we should localize mime types.

[gneissone]

I believe @chenejac is suggesting the text MIME Types: itself should be i18n, not the type list of options. Looking at wiki (e.g. tipos MIME in spanish), I think it would be beneficial to have it internationalized.

[litvinovg]

Thanks, Benjamin. Sure, I will fix that and prepare PRs for VIVO-languages and Vitro-languages.

[litvinovg]

I improved internationalization, naming, removed extensions information in favor of media types.

[gneissone]

Gave this a test run. It appears to work well. I think we could improve some things, but I'm opening to merging as is (after a couple small requested changes) if everyone thinks we should get in the code now and improve later.

storedFile only appears for classes set as domain.
Upload works!
Respects allowable mime type list.
Respects max file size.
Deletion works. Removes file and related triples.

Changes requested

• Example fileUpload.maxFileSize text is missing a zero (says 1048576 bytes is 10mb, but it's actually 1mb).
• 'storedFile' property does not have a public label. Should add i18n labels.

Questions, observations and additional suggestions

• Allowable filetypes not known/shown when uploading via the 'plus' icon on a page. Perhaps the user should be sent to the upload form where there are more details, rather than going straight to the upload dialog. Alternatively, the allowable file types should be shown next to the 'plus' on the list view.
• If no mime types are set in runtime.properties, form still appears, but won't accept any files. Could argue that if admin made decision to set the domain of storedFile they should have also set the accepted mime types.
• Default VIVO runtime.properties should also include examples of new settings. The Vitro example file is overwritten by VIVO during install.
• Must the application rename filenames when stored in file_storage_root? This diverges from the photo uploading behavior.
• Design that requires domain of 'storedFile' to be set in order for the property to appear isn't ideal from a management standpoint. Domain unions cannot be created or edited through the UI. If we stick with this, perhaps VIVO should ship with a predefined union of applicable classes.
• VIVO templates could add a file upload icon and list toward the top, rather than burying the files within the 'other' list view tab. I would argue the feature is important enough to be treated different than a standard object property.

[litvinovg]

• Fixed fileUpload.maxFileSize in configuration example
• Added public label for storedFile property (created vitro-languages-home-core to put properties in Vitro-languages)
• Added error message on form if no mime types cofigured

[gneissone]

• Fixed fileUpload.maxFileSize in configuration example
• Added public label for storedFile property (created vitro-languages-home-core to put properties in Vitro-languages)
• Added error message on form if no mime types cofigured

Tested, label is working. We will need to make a note in the upgrade documentation that the label will have to be added manually unless we resurrect the upgrade scripts that would automatically insert the new label from firsttime. Thoughts @brianjlowe ?

Overall, this looks good. I have requested a change to the vitro-languages PR and have a question on the VIVO PR.