hyrax
hyrax copied to clipboard
Thumbnail does not update when new version of file is uploaded, if new file is of a type that should display no-thumbnail image
Background info
Version observed in: Hyrax 1.0.2 Possibly related tickets: #1152
Rationale
Thumbnail shown for a file should always match the current active version of the file.
Expected behavior
Uploading a new version of a file, or restoring a different/previous version of the file, should always display the corresponding version's thumbnail image, even when that thumbnail image is the default/"no-image" image, i.e.
Actual behavior
Instead, the work's list of files displays the thumbnail image from the previously active version.
Steps to reproduce the behavior
- Upload a fileset to a work, with a file that successfully characterizes and "derivatizes" - for example, a JPG or PDF. Note that the thumbnail image (when ready) shows successfully.
- Upload a new version of the same fileset, with a file for which a thumbnail is not generated; for instance a plain-text file. While the new version of the file itself can be correctly downloaded, the file is now shown with the thumbnail image from the previous version. The expected behavior is that it should show with the "no thumbnail" default image of
We should verify this in 2.0 as well.
tested this locally and i'm seeing that one must reload the page for the thumbnail to change.
@kerchner can you test this again?
Closing as fixed
👍
Saw the links to this when working on #1152 It was never fixed. Reopening it.
It's kind of the same deal as that issue, only instead of a post-versioning cleanup of characterization data in Solr, what's required is a cleanup of derivative files. This makes sense to do anyway, but in the specific case mentioned in this issue, i.e. when the incoming version's mime_type should result in no new derivatives being created, it is essential. Otherwise the representative (thumbnail etc) does not relate to the downloadable file and so on.
Thankfully, it looks like once you've deleted the derivative file(s) on disk in advance of them not being recreated, the indexing operations for the FileSet (and any Work and/or Collection that might use it as a thumbnail/representative) will see that no representative exists and take care of indexing the default . See IndexesThumbnails, ThumbnailPathService, WorkThumbnailPathService and CollectionThumbnailPathService.
Now, the awkward thing about the way the code is laid out is that the cleanup operation cannot be put in CreateDerivativesJob
because, by the time that is run, the FileSet holds the new version's details and mime_type
. And, crucially, if the mime_type
does not match a "valid" derivative service then cleanup_derivatives does nothing. And of course, we're here in this issue purely because of files that do not match types supported by the default FileSetDerivativesService.
Anyways, that's the way I initially attempted to fix this problem, putting a cleanup in CreateDerivativesJob. But I'll have to shunt that earlier when the old version is still current. Probably in a content update method in an actor?