hyrax icon indicating copy to clipboard operation
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

Open kerchner opened this issue 7 years ago • 5 comments

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. image

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 image

kerchner avatar Jul 14 '17 18:07 kerchner

We should verify this in 2.0 as well.

mjgiarlo avatar Jul 14 '17 18:07 mjgiarlo

tested this locally and i'm seeing that one must reload the page for the thumbnail to change.

@kerchner can you test this again?

vantuyls avatar Dec 20 '17 20:12 vantuyls

Closing as fixed

mcdowney avatar Sep 26 '19 15:09 mcdowney

👍

kerchner avatar Sep 26 '19 15:09 kerchner

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?

conorom avatar Mar 15 '22 17:03 conorom