Overdrive API integration

Bug #1410537 reported by Jeff Davis on 2015-01-13
This bug report is a duplicate of:  Bug #1541559: OneClickdigital API integration. Edit Remove
This bug affects 7 people
Affects Status Importance Assigned to Milestone
Jeff Davis

Bug Description

Here is some code for integrating the Overdrive API into the TPAC. If possible, we'd like this code to be adopted and supported by the Evergreen community, ideally in time for the release of EG 2.8.

Sitka has been developing some code that uses the Overdrive API to allow Evergreen users to perform certain Overdrive-related actions directly within the OPAC, including:

- check out a title
- place hold on a title
- view patron's current holds/checkouts
- suspend and cancel holds

The code for this project now lives in a contrib repo on the Evergreen git server:


This is a Javascript-based add-on or overlay to the existing OPAC. It has a few dependencies that are new in Evergreen, including jQuery and require.js. The build-and-install process is outlined in the README. To actually enable/integrate it, a few minimal changes would need to be made in the TPAC, along the lines seen in Sitka's Evergreen repo here:

Sitka has already deployed this in production for one of our libraries (we are running EG 2.6 with some customizations), but we don't want to retain ownership of the project in the long term. It would be great if the new functionality could be made generally available alongside the 2.8 release of Evergreen, either integrated directly into the main EG codebase (unlikely) or as a supported add-on (more likely).

A few considerations that have been raised so far:

1. As written, this code introduces new dependencies (jquery, jquery-ui, require.js) which aren't currently used by Evergreen. Are we comfortable with that? If not, can/should we rework the code to remove the dependencies, or re-implement Overdrive integration from scratch using whatever can be learned from this project, or...?

2. The code is written in Coffeescript and needs to be compiled to JS before deployment. This requires a recent version of node.js; the packaged version of node.js in Ubuntu 12.04 does not work (although 14.04 does). How should Evergreen accommodate these build requirements?

3. The code is tightly coupled to v1 of the Overdrive API. It may not be easily extensible to work with related APIs such as OneclickDigital's.

4. Some parts of this code are, as Galen put it, "delicate with respect to changes to the TPAC templates," so that minor changes to a .tt2 file could break Overdrive API integration.

5. The code was written under contract for Sitka (with copyright assigned to the BC Libraries Cooperative) and initially published under an MIT license, but the license and copyright statement were added to the source code relatively late, and not by the original developer. It may be desirable to further clarify copyright and licensing of the code.

6. I need to add more documentation. :)

Ben Shum (bshum) wrote :

Adding initial review target of 2.8 beta as requested in IRC.

Changed in evergreen:
milestone: none → 2.8-beta
status: New → Triaged
importance: Undecided → Wishlist
Holly Brennan (hollyfromhomer) wrote :

Question: Would this eliminate the need to import/catalog Overdrive records into Evergreen? (Hey, no such thing as a stupid question, right?) This is where our staff is really bogged down. The most time is spent cataloging the records for items in Overdrive.

This is still a great thing, if only it shows availability of Overdrive records without having to jump over to the Overdrive site. However, it would be fantastic if somehow the API would do all the work of searching records on Overdrive as well, without us having to do the cataloging work as well.


Jeff Davis (jdavis-sitka) wrote :

That's a great question!

No, this doesn't eliminate the need to import Overdrive records. When you do a search or look at an individual bib record, you are dealing with the records in your Evergreen system. This code just uses the API to look up availability data on Overdrive titles that are already in your system (and lets you do checkouts and holds on those titles from within the Evergreen OPAC interface).

Overdrive does have a search API. So in theory, if you wanted to avoid importing Overdrive records, you might be able to create some sort of federated search interface that allows a user to search both EG and Overdrive simultaneously. But the code we've got does not do that.

At Sitka we do automated imports of Overdrive records. We have some custom scripts for grabbing an up-to-date set of records from Overdrive, processing the records, and inserting them into Evergreen. There's almost no staff time involved. Maybe a solution like that would work for you?

Holly Brennan (hollyfromhomer) wrote :

Jeff, thank you! Yes, we need to automate the process. It was my job to import these Overdrive records when our library was running Sirsi - but now my job has changed and I don't have the time (and now we're on Evergreen). Unfortunately we waited too long to get the next person trained up on the task, and now he has no time as well.

I would be very interested in Sitka's process for importing the records!

Ben Shum (bshum) on 2015-04-02
Changed in evergreen:
milestone: 2.8-beta → 2.next
Changed in evergreen:
assignee: nobody → Jeff Davis (jdavis-sitka)
Jeff Davis (jdavis-sitka) wrote :

See also bug 1541559.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers