Skip to content
This repository has been archived by the owner on Mar 20, 2023. It is now read-only.

Universal Viewer display does not reflect new file version #253

Closed
rjkati opened this issue Apr 6, 2018 · 7 comments
Closed

Universal Viewer display does not reflect new file version #253

rjkati opened this issue Apr 6, 2018 · 7 comments

Comments

@rjkati
Copy link

rjkati commented Apr 6, 2018

Reporting for

Testing for Hyrax 2.1.0 beta 2
Browser: Chrome 65.0.3325.181 (32-bit)

Descriptive Summary

Example: https://nurax.curationexperts.com/concern/generic_works/db78tc05q?locale=en#?c=0&m=0&s=0&cv=0&xywh=-319%2C-3%2C1273%2C438

I have created a public work and attached an image (rubber duck in the linked example). I would like to upload a new version of the image. I click on the image title in the "Items" section, then "Edit this image", then the Versions tab to upload a new version. After uploading a new version (Old well in the linked example), I navigate back to the Work page. The Universal Viewer still displays the old image. The thumbnail in the Items section displays the new image. I can download the new image.

Expected Behavior

When a new version of a file is uploaded to a Work, the Universal Viewer should display the new version.

@julesies
Copy link
Collaborator

julesies commented Apr 9, 2018

waiting on move to hyrax for some testing by @cjcolvar

@cjcolvar
Copy link
Member

cjcolvar commented Apr 9, 2018

I think this is an issue with riiif naively caching files it downloads and then never expiring them: https://github.com/curationexperts/riiif#images-retrieved-over-http . If one were using a different iiif image server they probably wouldn't run into this issue. This could be solved in riiif by making the default http file resolver smarter or in hyrax by configuring riiif to use a hyrax-specific file resolver: Riiif::Image.file_resolver = Riiif::HTTPFileResolver.new

@kefo
Copy link

kefo commented Apr 10, 2018

When using riiif or a hyrax-specific http/file resolver, is it safe to assume the source of the images is always Fedora? If yes, is it only one or perhaps both?

I ask because if riiif and/or a hyrax-specific always fetch from Fedora, the most elegant solution is to use the If-None-Match header and check if the Etag is the same. Yes/no? If riiif needs to remain resolver agnostic, perhaps hyrax can safely make the assumption (?).

(cc @RudyOnRails)

@cjcolvar
Copy link
Member

@jcoyne Do you have any thoughts on the best approach to solve this?

@jcoyne
Copy link
Contributor

jcoyne commented Apr 10, 2018

RIIIF is configured to use a simple HTTP::FileResolver https://github.com/curationexperts/nurax/blob/master/config/initializers/riiif.rb#L1. You could provide your own resolver to use whatever sort of caching strategy you want.

@elrayle
Copy link
Contributor

elrayle commented May 8, 2018

Down graded to non-blocker. Removing MustFix for Release label.

@julesies
Copy link
Collaborator

moved to hyrax issues, closing

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

7 participants