ualbertalib / discovery

Discovery is the University of Alberta Libraries' catalogue interface, built using Blacklight
http://search.library.ualberta.ca
12 stars 3 forks source link

Placeholder issue for suppressing the Place Hold button when HathiTrust link is present. #2003

Closed ghost closed 4 years ago

ghost commented 4 years ago

This may not become necessary, as SLT still needs to make a decision on "curbside pickup", but that's likely to be decided on soon. I just want to capture the scope of this fix and take an initial stab at an easy way it would work.

Our initial understanding of HathiTrust's ETAS programme was that when we restored access to the print collection we would have to remove the HathiTrust ETAS links (i.e. ETAS is only allowed when there is no access to the print collection). Clarification from HathiTrust sent out on Friday indicates that access to the print collection can be restored as long as ETAS items are not accessible. Because curbside pickup will be staff mediated, we can ensure this happens by suppressing the Place Hold button on records that have a HathiTrust link.

I think the simplest solution is probably just as follows: if the hathitrustlink div is present, then suppress the btn hold CSS class. There's another link in _place_hold.html.erb, but it doesn't have an identifier, so I'm not sure how best to suppress that link. This is just a suggestion, there may be better ways to implement this feature.

@mbarnett raised the question of users possibly figuring out how to construct a place hold link on their own to bypass the record link and place a hold that way. I don't think it's worth trying to build in the extra logic to prevent that at this stage.

theLinkResolver commented 4 years ago

@weiweishi I don't know what the usage is like for the classic catalogue these days, but that would allow unfettered access to these items if/when we get curbside rolling. I wonder if we have to acknowledge this risk somewhere along the way.

ghost commented 4 years ago

@theLinkResolver Oh, that's a good point... Offhand, I can't think of a quick/effective solution.

weiweishi commented 4 years ago

Removal of the hold button will reduce the amount of manual checks for Access Services, but I wonder if we can still build in some manual checks just to be sure?

Weiwei ShiAssociate University Librarian

2-10L Cameron Library, University of Alberta 780-492-7802 | weiwei.shi@ualberta.ca "The University of Alberta respectfully acknowledges that we are situated on Treaty 6 territory, traditional lands of First Nations and Métis people."

On Sat, May 30, 2020 at 7:37 AM redlibrarian notifications@github.com wrote:

@theLinkResolver https://github.com/theLinkResolver Oh, that's a good point...

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ualbertalib/discovery/issues/2003#issuecomment-636332097, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAPT47S5PQ7FW4XZXOKGY7LRUEDYXANCNFSM4NNAJDNQ .

ghost commented 4 years ago

CJ was keen to avoid his staff having to do manual checks, but there may not be a way around it. We can provide them with a copy of the HathiTrust overlap report, which might be the easiest thing. The only other thing I can think of is whether there might be away to indicate that a hold was placed through iLink vs. Web Services (a Web Services hold would indicate the hold was placed through Discovery and wouldn't have to be checked), but I can't offhand think how we would do that...

ghost commented 4 years ago

We've been trying to do this without requiring work on the part of Cataloguing or the ILS team (i.e. we've been trying to do this all in Discovery. But the safest thing would probably to have Cataloguing (or Jim if he can script it) change all the ETAS material to non-holdable. I don't know how we would account for multiple copies held by us (all but one of which should be holdable - perhaps we leave it holdable but take one copy out of circulation) or where copies are held by U of A and another NEOS library. I think this is likely not something for us to tackle with development work in discovery, but rather something for the ILS team or CatMet.

mbarnett commented 4 years ago

It would probably be worth flagging this to CJ, since I believe he’s running with the estimate I gave him for doing this in Discovery in the proposal he’s putting together.

ghost commented 4 years ago

Thanks Matt - I've sent an update to the email thread from last week. I'm a bit confused as to what is supposed to go to the whole working group and what just needs to go to CJ, Lindsay, and Angie, but I'm following CJ's lead on that one.

theLinkResolver commented 4 years ago

@redlibrarian @weiweishi I referenced classic (iLink) in my earlier message but I guess another loophole is NEOS discovery.

ghost commented 4 years ago

@theLinkResolver I think NEOSDiscovery will be less of a concern because our users don't tend to use it (as far as we know) and since Symphony is supposed to restrict loans to each library's home users, it should be OK. Still a risk, but I would put it at around the same level as a user figuring out the Place Hold URL.

In any event, CJ is going to recommend the manual approach to SLT - an Access services staff member vetting hold requests, which is the most work but perhaps the quickest safe option.

ghost commented 4 years ago

I passed along our thoughts to CJ who has decided that the best thing to do at least in the short term is have Access Services staff to a manual check on whether a requested item is an ETAS item. I think the next solution after that would have to be done by CatMet. As a result I'm closing this issue. We can reopen it if the issue comes up again.

mbarnett commented 4 years ago

Reopening to cover the minimal implementation agreed to w/ Weiwei: we're going to suppress the hold button in Discovery whenever the record is in the overlap table, without regard for whether or not the item is actually still available via the HathiTrust API, and knowing that the overlap report is not currently being refreshed in a timely manner.

To be clear: this means that we 100% expect that there will be corner cases in which the hold button will be unavailable but no access in HathiTrust button will be present, because the item is unavailable through their API. This is not a bug, this is a compromise we are making to do this in a timely manner – users are expected to contact public services to resolve access to those items. Weiwei will communicate this expectation to public services.