New iBorrow Build: Test Drive Results
The latest build of iBorrow was installed on our server in Provo Friday evening, and we tested it over the weekend. Our assessment so far is that it passes the test nicely. Here’s some detail.
Java 1.6 compliance: Yes. No problems at all.
Faster “Edit Request” response: Well, maybe. A little faster, I think. It’s not yet what you would call ’speedy’, but if you can set up a three way race with MS Vista and a glacier as the other two competitors, you can bet on URSA.
Proxy Request Improvements: The patron’s barcode is now readable as you type it in. Yayyy!
Incoming Loan to Fill Loan: This one is lovely. It is still true that URSA can’t place a hold on your local system, if it can’t give your server a single unique bib record to request. That is why ISBN’s are so important. But there are several other things that can drop a request into your Incoming Loan box, even if it has an ISBN. Most of these are transient. So, if you could try again, the hold would take. The new build lets you do that. If you go to your Incoming Loan space and find requests there with ISBN’s, you can right click on each request, choose Process Request, and watch it go to Fill Loan. That’s not the important part, though. The important part takes place in your server, where a Hold gets placed, and a copy will show up on someone’s pick list tomorrow morning.
More Detail in History: I’ll send this out to you as Email and attach a spreadsheet Holly gave us. When you edit an item now and look at its History, you (and SirsiDynix Support) will see a lot more information.
Availability Rules and LOLR Issues: These weren’t really testable over one weekend. Time will tell us how much closer to ‘perfect’ iBorrow/URSA is at following the Availability Rules and properly routing requests that run into LOLR issues.
As we learn more, we’ll share it with you. And I trust you to tell me when you find something that doesn’t work.
–Al Carlson