Enhanced Patron History

One of my recent projects has been to enable patron check-out histories on our website. I had been a little apprehensive about it for several reasons. First, because all of our ILS functionality must be either duplicated, or passed through Drupal, I felt that this was going to pose some serious logistical problems. Getting information from point A to point B quickly and securely using our model can be tricky, doubly so, given that the back-end can be a nightmare of non-standard mish-mash. Second, because patron check-out history is a more complex beast than, say, simply displaying current checkouts. And third, because III’s check-out history is so dull and useless, I wanted to add some additional functionality such as filtering, searching, and, of course, RSS feeds.

There are several components to the patron history system. The opt-in mechanism is controlled by Drupal’s profile module, which allows you to create custom, user-specific preferences. I’ve consolidated ours together on the patron account page, it looks like this:

A patron can easily maintain their preference set via Drupal’s nice profile option interface. All I had to do was write a hook into that particular profile option that controls the behavior of the patron history middleware.

Which brings me to the next major component. The patron history middleware. This is where I interface with the III server and perform all the history-related stuff. Getting the data from III actually was less of a tour-de-force than I thought it might be. If you’re interested in details, email me.
The middleware ensures that all history data gets siphoned through a function that adds material code, record summary and author info then is stored in our own mysql database. This allows us to do things like search history data by title, author, keywords and filter by material type.

The last component was the actual UI that is presented to the user. It basically brings together the functionality made possible in the middleware (the items in this history were just for testing):

The point of sharing this with you? To illustrate that we can do a much better job than the vendor itself. Yes, we can figure it out, and we will. I didn’t have an API to work with when I did this, and searching patron history is not even an option in III, nor are RSS feeds of patron history (and RSS feeds of custom patron history searches). How great it would be to have the proper tools to do this kind of work.

I’m reminded of Stephen King’s, Storm of the Century, “Give me what I want and I’ll go away“.

About this entry