Syrup Reserves + Evergreen
Graham Fawcett
If you're interested, I'd like to take a stab at implementing your
reserves requirements in Syrup. Let me walk through a short proposal,
and see what you think.
Reading your earlier emails, I think these are the major workflow steps:
* put bib records into Syrup course-sites.
* associate course sites with start/finish dates and reserves locations.
* near start-date, find local copies, and route them to the right
reserves location.
* wait for copies to arrive, and note their arrival.
* after finish-date, route items back to their permanent locations.
Put bib records into Syrup course-sites
---------------------------------------
* via catalogue-search in Syrup (available now)
* via 'import' of EG record-URL or bookbag-URL (available now)
* import from My Bookbags, or My Record Buckets (todo)
* 'push' from the staff client, and/or from the EG Web interface, into
Syrup (maybe-todo, if you want)
* manual entry of bib record in Syrup (eww, maybe todo), or at least
entry of partial bib information (with the record to be looked up by
library staff). I think Karen Schneider suggested this.
Push/pull between Syrup/EG will require a shared authentication
scheme, or at least an identity-matching scheme. We haven't required
that Syrup user-accounts are associated with ILS accounts. At some
institutions, it might be more likely that Syrup would accounts with,
e.g., a course-management system or a campus SSO system.
Associate course sites with start/finish dates and location
-----------------------------------------------------------
* Dates will typically be based on the campus semester/term
system. Maybe the dates could be overridden on a course-by-course
basis.
* Can we assume a single reserves location for a given course? (If
not, maybe we could associate Syrup course sub-folders with
different locations, if needed.)
Near start, find copies and route to reserves location
------------------------------------------------------
* Try to auto-discover available copies: let Syrup look them up. If
found, change their circ-modifiers/location. Email someone to notify
them of the change. Obviously some library smarts will be needed
here, but I imagine that a good algorithm could discover most
copies.
- Syrup would have an Evergreen userid, so that these automatic
changes would happen under a common account.
- the discovered copy records would be placed in a copy-bucket,
representing 'copies expected at reserves location X on a certain
date.' We'll keep the bucket around, at least until the items have
all arrived (or have been cancelled, substituted, etc.).
* When copies cannot be automatically discovered, drop the bib records
into a record bucket, and email the staff. Staff will look up
copies, and pop the copies into a copy bucket (so that we can
associate the copy with the bib-record reserves-request, and then
change the copy's circ modifiers).
- Question: Can copy buckets be shared, like record buckets? Can you
copy copies from one copy bucket into another in the staff-client?
I think it's important that there be one copy-bucket associated
with each record-bucket that's handed to the staff. But I don't
know how awkward that would be in the staff client. Maybe we could
add it on the Syrup side.
Wait for copies to arrive, and note their arrival
-------------------------------------------------
* Optionally, email the prof as copies arrive.
- How will Evergreen know when the copies actually make it to the
reserves location? Does someone scan them? Or do you go on faith?
- For copies that don't arrive in time, raise a notice to the
reserves staff and possibly the prof.
After finish-date, route items back to their permanent locations
----------------------------------------------------------------
* Change the modifiers and send them home.
Thoughts?
Graham
Art W Rhyno
This looks good, I think the integration layer would be greatly facilitated by the python opensrf support [1]. I have been using opensrf from both visual basic (for excel) and cocoon (for authentication and patron registration), and it can jump really intricate hoops. For example, this is how a bookbag gets pulled into excel from conifer:
parms = "method=open-ils.actor.container.retrieve_by_class&service=open-ils.actor¶m="""
parms = parms & authToken
parms = parms & """¶m="
parms = parms & userVal
parms = parms & "¶m=""biblio""¶m=""bookbag"""
oHttp.Open "POST", sURL, False
oHttp.setRequestHeader "Content-type", "text/xml"
oHttp.setRequestHeader "Content-length", Len(parms)
The "authToken" comes from a different call, but I suspect the python opensrf library [1] makes this even more seamless. The notion of a syrup account id fits in well with how we are doing patron registrations, where ldap is used to get the university of windsor identifier (uwinid), the uwinid is used to match the record in the student information system (SIS) export file, the data in SIS is reformated to be passed to conifer through opensrf, and the authentication token is based on a staff account created for this process.
I would be leery of shifting any cross-bucket management into conifer, the authentication scheme would be cranky about the permissions for scenarios where an item had to be moved across buckets. I could see endless bookbags for the syrup evergreen account id however.
Maybe if we worked through an example? So a prof requests "No great mischief":
http://windsor.concat.ca/opac/en-CA/skin/uwin/xml/rdetail.xml?r=1894792&t=no%20great%20mischief&tp=keyword&l=106&d=1&hc=11&rt=keyword
There are 4 copies, 1 is checked out, 1 is in a non-circulating location, and 2 are in the circulating collection. Syrup goes for an available copy in a circulating location first (this could be determined with opensrf). Syrup then:
1) changes the location of the item to "reserves" or whatever
2) changes the item to be non-circulating
3) adds it to the booklist of items to be pulled
4) manages the e-mail notifications of the above
The staff could change the circulation flag when the item is in hand, this keeps the material in the building until it is ready. And maybe the "arrive in time" sequence could key on when the circulation flag is modified, e.g., if the item for "No great mischief" is still non-circulating after x days, then something needs to be escalated in the processing?
One thing that may help with all this is that the test server has a proper domain name now - "test.concat.ca" (thanks to Dan). I needed to do a special workaround to add a security certificate exception to cocoon when I first set up the patron registration testing and some environments might have had bigger issues over it, but I think this shouldn't cause any headaches now.
art
---
1. http://www.open-ils.org/dokuwiki/doku.php?id=opensrf:python