Fulfillers (and end users?) should be able to download original files

[escowles]

Related to #765

Fulfillers should be able download original files, without necessarily having access to the file manager. This could be part of the viewer, or a separate file listing.

Should we also allow end users to download original images from the viewer?

[sdellis]

Should we also allow end users to download original images from the viewer?

I think so, probably by implementing the IIIF Auth spec with one of our payment gateway options. I think that making this feature "self-service" would improve the overall experience for both the Patron (immediate satisfaction) and Staff (no needless work).

The only issue we may run into is "curatorial approval", but that would only apply to work that Princeton owns the copyright to, which is actually very small.

[tpendragon]

Implementing a payment gateway here seems super low priority to the extent that if we want to talk about patron self service we should make another ticket for it. We'd have to have some extensive use case discussions.

[escowles]

Yes, I haven't heard anyone suggest we need a universal payment option for downloading files — different locations have different policies about some of these things, and rationalizing them could make sense — but we would need our stakeholders to be interested in that before we should do any work on something like that.

For this ticket, I think we should allow authorized users to download the original files from the viewer. Maybe @jpstroop knows if we should also allow end users to download original files, or if we should start gathering input on that.

[tpendragon]

Did a quick test: if we add a rendering to each canvas with the full resolution download link it'll show up in UV.

[sdellis]

I think that the rendering approach will allow fulfillers to get to the originals without having to go through the Filemanager/FileSet screens.

[sdellis]

The only thing is that it should only allow full download from within Figgy, not in the public UV. Does that mean different manifests for Figgy use and Catalog/Public UIs?

[escowles]

@sdellis Ideally, it would show the rendering for people with the right permissions to download the full-resolution images — regardless of whether they were searching in Figgy or Orangelight.

[sdellis]

Yes, that would be ideal. However, IIIF Auth only works for resources within the info.json. So, we may need to generate and cache different manifests for those with permissions and those without, and user permissions would have to be managed across systems somehow.

On the other hand, there is some interest in Proof of Concept work for allowing the IIIF Auth API to work with non-ImageAPI resources: IIIF/api#1290

[escowles]

@sdellis I don't think it would be hard to generate different manifests depending on whether the requesting user was logged in or not. Managing the auth across Orangelight and Figgy is harder: if you're logged in to Figgy and load the viewer in OL, does the request to get the manifest from Figgy include the headers/cookies so that Figgy knows you're logged in? Would it be possible in OL to know if the user was logged in to Figgy and show some indication?

[sdellis]

@escowles I think it's fine for now to manage access through Figgy, since the pressing use case is the fulfillers. It can be simple: anyone logged into Figgy gets the manifest with the rendering property via Figgy.

Eventually, if we want to grant access to restricted items through other systems (i.e., virtual reading room, self-service fulfillment, etc.) we will have to implement an authorization service that complies with the IIIF Auth Spec. This is a much bigger challenge, but I don't think we have to worry about it for the moment.

[escowles]

@sdellis That sounds good. So for this ticket, we can just including the rendering link to the TIFFs so the fulfillers can download them.

[sdellis]

@escowles 👍 Yes, including the rendering link to a manifest when the user is logged in to Figgy will close this ticket.