Our library serves several remote field stations that have small unstaffed reading rooms and we occasionally get interlibrary loan requests from researchers at these sites. We generally choose to mail physical items to these users and wanted a way to differentiate and catch these unique requests so they aren’t cancelled or just placed on the hold shelf. Our current solution is to include a “Primary Location” on the user registration form that populates the user “Site” field in ILLiad. This involved several steps.
First, I added these values to the CustomDropDown menu in the Customization Manager (System -> General -> CustomDropDown).
The new user registration and change user information webpages were updated to include the following code:
<span class=”field”><span><b>Primary Location:</b></span></span>
<select id=”Site” name=”Site” size=”1″ class=”f-name” tabindex=”4″>
<#OPTION name=”custom” groupname=”Site” selectedValue=”<#PARAM name=Site>” defaultValue=”MC” defaultName=”Main Campus” />
Once the webpages are edited, the LabelName ultimately displays to users on user registration/information pages.
The LabelValue displays in the user information under “Site.”
Finally, I created a custom queue and a routing rule to send all requests not coming from users on the main campus to their own queue.
The new custom queue is:
QueueName = Remote Site ILL Requests
ProcessTye = Borrowing
NVTGC = ILL
The new routing rule is:
RuleNo = (Pick a number useful to you. It’s actually our last rule because we want the electronic requests to automatically go to the user.)RuleActive = Yes
ProcessType = Borrowing
TransactionStatus = Awaiting Request Processing
MatchString = (u.Site = ‘RS’ or u.Site=’AEC’ or u.Site=’OT’) = Essentially the LabelValues that you want to go into their own queue.
So far this solution has really helped the ILL staff easily identify the few requests that need to be mailed to the remote sites and process them accordingly.
I’m in the process of setting up campus delivery using primarily ILLiad (more on that in a future post) and have found some interesting things regarding email templates in ILLiad 8.4.
In 8.4, email templates can reside and be customized in the Customization Manager. This makes updating emails easy … IF the templates were set up correctly to begin with.
To illustrate, I’m going to use ILLDDLoan as an example which is an email meant to notify users that physical items going through Document Delivery are available for pickup.
Looking at the Customization Manager -> Borrowing -> Email -> ILLDDLoanNotifyEmailFileName, I saw that the default Key Value was set to illddloan.txt. So with the troubleshooting mindset that only a few changes should be made at a time, I incorrectly created a new template in “Email Templates” with the name illddloan.txt. Unfortunately, none of my test emails had the new and correct information. I did some further investigation and found the ILLiad 8.4 Guide to Creating and Editing Email Templates – Default Email Templates. This resource pointed out that several of the email templates that I am interested in changing are stored in the ILLiad database and have a specific file name that does not end in .txt. So in my example the file name should be ILLDDLoanNotify not illddloan.txt.
Correct Email Template
I have since made changes to the Email Template names but not the …EmailFileName keys located elsewhere in the Customization Manager. I find it odd that I didn’t have to change the name in both locations, yet am very happy the emails are working well.